App security follow-up: MSign replay-protection dedup, content scanning, retention policy

Context

Split out from #162, which is now closed. #162 resolved every code-checkable gap in this section via real inspection (SSRF confirmed wired-in, CSRF confirmed N/A, SSE/MCP auth confirmed correct) and found one real, precisely-scoped gap.

The real finding: MSign per-request signing has no true replay protection

musehub/auth/request_signing.py's ts check only bounds freshness (default 30s skew) — it does not track or reject a duplicate (handle, ts, sig) replayed within that window. The codebase's own auth-challenge flow and MPay both use single-use nonces with DB uniqueness constraints; the per-request MSign scheme has no equivalent. Docstring corrected to describe this accurately (2026-09-07) rather than leaving the overstated "replay protection" claim in place.

• Build the actual fix: a short-lived (handle, sig) dedup cache checked on every authenticated request. Needs real design work — a write on every authenticated API call has real performance implications, and it needs to work correctly across the blue/green instance topology (shared store, not per-instance memory). Options: a Postgres table with a TTL/cleanup job, or a Redis-backed cache if one gets introduced for other reasons.
• Assess actual exploitability before prioritizing the fix — requires an attacker to capture a validly-signed request within its 30s window (network position, compromised proxy/logging, or edge-layer visibility given Cloudflare terminates TLS there) and the replayed action needs a non-idempotent side effect to matter.

Other remaining items

• Uploaded content scanning (malware/content scanning beyond size/structure limits)
• Data classification and retention policy — organizational decision, not a code question
• Formal OWASP-oriented pass — #161 (closed) and #162 together cover most Top 10 categories; a dedicated pass in Section 17 (Testing Before Launch) should build on these findings