PREWAVE-BE-106 — Persist Support Requests with Privacy-Safe Retention #807

Problem context

SupportRequestService accepts public support requests but stores records, duplicate fingerprints, and quota history only in process-local Maps. A restart or second API instance loses requests, duplicate suppression, and contact quotas. The service also handles contact details and user-submitted diagnostics, so persistence must be privacy-controlled.

Technical scope

Persist support requests through a dedicated database model and migration. Keep the existing normalization, sensitive-content filtering, duplicate window, per-contact quota, 30-day retention, and deletion semantics. Use a keyed fingerprint over normalized fields rather than persisting a reversible base64 encoding of contact/description data. Encrypt or appropriately protect contact/evidence fields at rest, limit access to authorized support roles, and implement a scheduled retention purge. Make duplicate detection and quota enforcement atomic across API replicas.

Required tests

• Requests survive restart and are visible across replicas.
• Duplicate and quota checks are race-safe under concurrent submissions.
• Contact and description fields are protected and omitted from logs.
• Retention purge removes expired records and corresponding fingerprints.
• Public submitter cannot enumerate or fetch another user's request.
• Migration up/down and deletion behavior are tested.

Security and architecture constraints

• Durable state must be consistent across restarts and replicas where the feature is user-, privacy-, security-, or operations-critical.
• Fail closed when persistence, authorization, policy version, or source provenance cannot be verified.
• Keep protocol authority in canonical contracts and finalized event projections.
• Protect contact details, consent records, subject identifiers, capabilities, and audit metadata.
• Do not create new protocol mutation authority in API services.

Acceptance criteria

• The process-local-only behavior is replaced by a durable/shared implementation where required.
• Ownership, role, and privacy boundaries are enforced.
• Concurrency, restart, retention, and failure behavior are covered by automated tests.
• Documentation describes the persistence and operational model.
• Exact-head required CI passes and independent review is recorded.

Dependencies

• The existing support DTO, privacy filter, and authorized support-review boundary must remain the contract.

Non-goals

Building a full ticketing platform, adding public request enumeration, or extending retention beyond policy.

Complexity and points

• Medium — 150 points

Candidate only. Activation remains maintainer-controlled; do not apply Stellar Wave as part of implementation.