Move x/crypto to v0.55.0, clear of the ssh CVEs

v0.10.1's image published, but scan-image refused it. trivy reports ten
HIGH advisories against golang.org/x/crypto v0.49.0, CVE-2026-39828
through CVE-2026-56854, all of them in x/crypto/ssh and its agent and
knownhosts packages. The last is fixed in 0.55.0 and the rest in 0.52.0.

None of them is reachable here. The server imports x/crypto/bcrypt and
nothing else from the module, and the image is FROM scratch, holding a
single binary. But trivy scans at module granularity and cannot tell
that. Shipping a known-vulnerable module version on the strength of a
reachability argument is not the call to make inside a dependency pin,
so the version moves instead.

9abf07f was wrong to call v0.49.0 the newest release that keeps go.mod
at go 1.25.9. v0.55.0 keeps it there too; the directive is unchanged
here. What had held it at 1.26 was the x/sys v0.48.0 that v0.57.0 pulled
in. The `go get golang.org/x/sys@v0.42.0` meant to undo that then
downgraded x/crypto to v0.49.0 to match, without being asked. x/sys now
sits at v0.47.0, the version x/crypto v0.55.0 requires.

Checked before tagging rather than by the pipeline: the gate passes, the
Dockerfile builds on its Go 1.25 builder, and trivy, run locally with
the same flags as `make security-image` (HIGH and CRITICAL, fixed only),
exits 0 on the image that build produced.

go.mod

@@ -4,7 +4,7 @@ go 1.25.9
 
 require (
 	github.com/go-chi/chi/v5 v5.2.5
-	golang.org/x/crypto v0.49.0
+	golang.org/x/crypto v0.55.0
 	modernc.org/sqlite v1.50.1
 )
 
@@ -14,7 +14,7 @@ require (
 	github.com/mattn/go-isatty v0.0.20 // indirect
 	github.com/ncruces/go-strftime v1.0.0 // indirect
 	github.com/remyoudompheng/bigfft v0.0.0-20230129092748-24d4a6f8daec // indirect
-	golang.org/x/sys v0.42.0 // indirect
+	golang.org/x/sys v0.47.0 // indirect
 	modernc.org/libc v1.72.3 // indirect
 	modernc.org/mathutil v1.7.1 // indirect
 	modernc.org/memory v1.11.0 // indirect