fix: set baseline security headers on every API response (#251-#254)

[devgrace100]

Summary

Only the dashboard_asset handler set security headers — the three static dashboard assets. Every JSON API response — including payment records and freshly-minted API keys — was sent with no security headers at all.

This PR adds a baseline header stack to the root router (tower-http's set-header feature was already a dependency) so every response, including rate-limit 429s, timeout 408s, and the router's 404/405 fallbacks, carries them.

What changes

Applied outermost in src/api/mod.rs:

• X-Content-Type-Options: nosniff (overriding) — responses embed merchant-controlled strings (webhook_url, memo), so browsers must not MIME-sniff JSON.
• Referrer-Policy: no-referrer (overriding) — payment ids travel in URLs and would otherwise leak through referrers.
• Cache-Control: no-store (if-not-present) — POST /merchants returns a plaintext API key exactly once and GET /payments/:id returns payment detail; neither should be cached by an intermediary or written to browser disk cache. if_not_present preserves a handler that legitimately opts into caching.
• Strict-Transport-Security (if-not-present, conditional) — emitted only on public network deployments (STELLAR_NETWORK=public), where TLS termination is guaranteed; absent on testnet, where asserting HSTS over plain HTTP would be misleading.

The dashboard's stricter Content-Security-Policy is preserved, not overwritten.

Acceptance criteria

• nosniff, Referrer-Policy, and Cache-Control: no-store set on API responses
• HSTS emitted on public-network deployments only
• Dashboard's stricter CSP preserved, not overwritten
• Tests assert the headers on a representative API response (/payments/does-not-exist), HSTS per network, and CSP preservation on /dashboard

Note on scope

main did not compile at head when this work started (several referenced-but-missing support functions/config fields, a stale migrate() transaction tombstone, and a missing schema snapshot fixture). This PR also restores a buildable, test-passing baseline so the change lands on a green suite. Two pre-existing, unrelated failures remain out of scope for this issue and are documented in the PR description:

• cors_tests — build_cors advertises {get, post} but the router serves delete (tracked separately, issue CORS allows only GET/POST/OPTIONS and two headers, blocking DELETE, Idempotency-Key, and X-Admin-Secret #281).
• openapi_contract::openapi_documents_exactly_the_intended_paths — openapi.yaml path-set drift.

Closes

closes #251
closes #252
closes #253
closes #254

[drips-wave]

@devgrace100 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits