feat: report the version in a Nanopub-Router-Version header

[ashleycaselli]

Groundwork for showing the router in the Nanopub Monitor.

Why

The monitor fills its version column from a per-service response header — ServerScanner reads Nanopub-Registry-Version, Nanopub-Query-Version, Nanopub-Monitor-Version and Nanodash-Version from the instances it scans. The router sends no such header, so a router instance listed there would show an empty version.

Changes

• Nanopub-Router-Version on every response, via a withVersionHeader middleware alongside the existing withAccessLog.
• version is injected at build time with -ldflags "-X main.version=..." from a VERSION build arg; release.config.js passes ${nextRelease.version} to docker buildx build. A plain go build still reports dev.
• README section documenting the header and where the value comes from.

The header is set before the handler runs, so it survives handlers that write their status immediately — the 307 redirects, and the 503 /healthz returns for a missing or stale snapshot. That last case is the point: an instance that cannot route is exactly when you want to know which build answered.

Verified

Built with an injected version and exercised the running binary:

$ go build -ldflags="-s -w -X main.version=1.2.3-test" -o router-test .
$ curl -sD- localhost:18099/         -> HTTP/1.1 200 OK
                                        Nanopub-Router-Version: 1.2.3-test
$ curl -sD- localhost:18099/healthz  -> HTTP/1.1 503 Service Unavailable
                                        Nanopub-Router-Version: 1.2.3-test

Three tests added, covering the help page, /healthz, a 307 redirect, the unhealthy 503 path, and that version is never empty. go test ./... and go vet ./... both clean.

Note

gofmt reports main.go as unformatted — struct field alignment in Config, which predates this branch and is untouched here. CI runs only go test, so nothing fails. Happy to fix it in a separate whitespace-only PR rather than muddying this diff.

Not included

This only makes the router reportable. Two further pieces are needed before it actually appears in the monitor, and neither is in this PR:

1. A service intro nanopub announcing the instance — the monitor's discovery query is type-agnostic, so no allowlist needs changing.
2. A nanopub-router branch in the monitor's ServerScanner that probes /healthz rather than falling through to the generic GET / probe. Worth doing: / is the help page and always returns 200, so the generic probe would report a router with a stale snapshot as healthy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NnGpEQkFqCaf4AEQwwhFFn