test(golden): complete golden parity coverage for all 54 REST operationIds + coverage guard

[rado0x54]

What & why

The golden set was being treated as a proxy for contract completeness, but the oracle only covered ~20 of the 54 openapi.yaml operationIds — parity was generalized from a subset. This closes that gap: every REST operationId is now either goldened against the canonical TS backend or carries an explicit, reasoned exclusion, and a new guard makes the gap impossible to reopen silently.

Goldens are authored on a branch off develop (the TS reference the Go rewrite replays) — not Go handlers.

Coverage guard (the point of the exercise)

• golden-coverage.ts — committed manifest mapping all 54 operationIds → fixture(s) or { excluded: <reason> }.
• golden-coverage.test.ts — fails CI on any operation that is neither goldened nor deliberately excluded, on stale manifest entries, and on mapped fixtures missing from disk.

This is the golden-side analog of the mounted-route/operationId parity check: adding or renaming an operation in openapi.yaml forces a matching golden (or a documented exclusion) in the same change.

What's captured

• Harness: startTestApp gains opt-in db/accountRepo/keyRepo overrides (same pattern as the existing audit/actions/push repos), unblocking capture of account/admin/credential bodies against a real in-memory DB.
• 31 new fixtures across 5 new suites: golden-account (account read/update, admin accounts+delete+export-seed, keys, /api/version, /config.js, endpoint update/delete), golden-session (create→list→tail→close success bodies), golden-credentials (list/label/confirm/revoke with real step-up tokens + invite reads), golden-hydra (authorized-clients list/revoke, mediated DCR, consent-approve), golden-actions-push (pending-action get/resolve/deny, Web Push subscribe/unsubscribe).
• Normalizer: added client_id_issued_at (RFC 7591 epoch-seconds) to the shared TS-fold keys.

Deliberate exclusions (documented in the manifest, not silent)

• The 6 WebAuthn/consent /options endpoints — non-deterministic @simplewebauthn challenge passthroughs (same rationale already applied to startHydraLogin).
• finishHydraConsent — its { redirectTo } envelope is identical to finishHydraLogin (goldened as webauthn-login-verify); a true success capture needs a full DB-enrolled assertion ceremony. Deferred, documented.

Verification

• test:golden — 61/61 green, guard at 54/54.
• test:integration — 216/216 green (shared harness/normalizer changes, no regressions).
• typecheck, lint, spdx:check — all clean.

For the Go side (go-backend, when picked up)

The replay harness must mirror three normalization details: the new client_id_issued_at TS-fold key, the manual <ID>/<OUTPUT> folds (pending-action ids, terminal tail bytes), and the contentType field on the /config.js golden envelope.