Scan the source and the working tree too, not just the image

The image scan added yesterday reads the built artifact. It cannot see a
vulnerable dependency the binary never calls into, and it cannot see a
credential in a file that never reaches the image — this one is FROM scratch
and contains a single binary, so almost nothing in the repo is in it. Those
are two different questions and they need two different tools, which is why
riksdata and rd-web have run govulncheck and gitleaks all along.

Both run on every push and pull request rather than only on a tag, since
neither needs anything published.

Checked by hand before wiring in, as with the image scan. govulncheck
reports no vulnerabilities the code can reach, and gitleaks finds nothing in
the tree.

What govulncheck does report is worth writing down, because it is the
argument for having it. It found three advisories in chi and reports none of
them, all three being IP spoofing in middleware.RealIP, which router.go does
not use — it uses Logger and Recoverer. The analysis is symbol-level rather
than dependency-level, so adding middleware.RealIP would turn this red on
the next push. That is precisely when someone should be made to look, and it
is a plausible thing to reach for here, since the API sits behind a gateway
and real client addresses are exactly what RealIP is for. The fourth finding
is an integer overflow in golang.org/x/sys/windows, which a linux/scratch
image will not be calling.

Both gates were checked for the failure direction as well. gitleaks exits 1
on a private key block. Worth knowing when testing it: it allowlists
well-known example credentials, so the AWS key from Amazon's own
documentation does not trip it and proves nothing.

Neither reads git history. gitleaks runs with --no-git, which scans the
working tree, so it stops a secret on the way in and says nothing about what
is already committed.

Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN

README.md

@@ -671,10 +671,13 @@ a flaky incident in production rather than as a red build.
 ## Releasing
 
 ```
-push to main       → ci.yaml       gofmt, go vet, go test
-push tag vX.Y.Z    → release.yaml  same gate, then publish:
+push or PR         → ci.yaml       gofmt, go vet, go test -race
+                                   govulncheck, gitleaks
+                                   helm lint + render
+push tag vX.Y.Z    → release.yaml  the same gate, then publish:
                                      git.ryuvia.com/niklas/terdut-server:vX.Y.Z
                                      oci://git.ryuvia.com/niklas/terdut-server  X.Y.Z
+                                   then trivy-scan the pushed image
 PR to Ryuvia/charts →              bump the wrapper chart to X.Y.Z; on merge
                                    Flux reconciles and the release rolls out
 ```