fix(api): /healthz Cache-Control: no-store (BUG-API-300)

[mastermanas805]

Summary

• /healthz is the rule-14 build-SHA gate surface. Without Cache-Control, intermediaries (CF edge, browser fetch cache, NR synthetic) may return a stale commit_id for seconds-to-minutes after a rollout — silently breaking the "did the new image actually land" verification.
• Stamp Cache-Control: no-store so probes always hit the live pod.

Coverage block

Symptom:        /healthz returns identical JSON every call with no Cache-Control (BUG-API-300)
Enumeration:    rg -F '/healthz' internal/router/router.go (1 emit site)
Sites found:    1 (router.go:414)
Sites touched:  1
Coverage test:  TestHealthzShape asserts resp.Header.Get("Cache-Control") == "no-store"
                so a future deletion of the c.Set call fails before merge.
Live verified:  pending auto-deploy + curl -I https://api.instanode.dev/healthz | grep -i cache-control

Inbox reference

• BUG-API-300 (P2 — /healthz returns identical JSON every call — no Cache-Control)

Test plan

• go build ./... clean
• go vet ./... clean
• go test ./internal/router/ -short -count=1 green
• Live verify: curl -I https://api.instanode.dev/healthz | grep -i cache-control returns cache-control: no-store after auto-deploy
• Live verify rule 14: curl https://api.instanode.dev/healthz | jq -r .commit_id matches the merge SHA

🤖 Generated with Claude Code