chore: clear all reachable vulnerabilities, and scan for them in CI

[keonik]

govulncheck found three vulnerabilities reachable from this code. Nothing
was scanning for them, so they sat there — a version number does not announce
itself.

ID	Problem	Fix
GO-2026-6293	echo 4.11.3 — an encoded slash (%2F) bypasses route-level protection and exposes static files, reachable from e.Static in main.go	v4.15.3
GO-2025-3553	golang-jwt/jwt v3 — memory exhaustion parsing headers	N/A — v3 is unmaintained
GO-2024-2687	x/net 0.17.0 — HTTP/2 CONTINUATION flood	v0.23.0

govulncheck now reports zero, and CI runs it on every push so this cannot
quietly rot again.

The jwt migration is the only real change

v3 has no fix, so the only way out was v5. StandardClaims becomes
RegisteredClaims, which holds exp/iat as NumericDate instead of int64.

The wire format is identical — both marshal the same JSON numbers — so
tokens signed before this deploy keep validating and nobody is logged out
mid-session. That is the claim that matters, so it is asserted rather than
assumed: a test builds a token the way v3 built one and checks it still parses.

Two things improve as a side effect:

• v5 validates exp by default; v3 did not unless asked.
• WithValidMethods makes the algorithm check an enforced parse option rather
  than a test the keyfunc has to remember to perform.

Tests cover expiry, alg=none confusion, and a wrong signing key.

A build break this nearly shipped

go.mod said 1.21 while the Dockerfile built on 1.24, so the enforced
language version was never the shipped one. Current x/crypto and x/net
require 1.26 — and go mod tidy silently raised the directive to 1.26.0,
which the 1.24 builder cannot satisfy. That breaks the image build, not
the tests, so CI would have stayed green while the deploy failed.

Both are 1.26 now, the builder image moves with it, and I verified by
building the backend stage rather than trusting that it would work.

🤖 Generated with Claude Code