fix: minimize verifier contact-data retention

[mergemaven11]

Closes #187

What changed

• Move pending verifier email, optional message, and hashed verification token out of Impact Receipt confirmation arrays into a dedicated MongoDB receipt_verification_requests collection.
• Add unique token, unique active receipt/email, and TTL expiry indexes.
• Keep only the minimum pending/completed attestation fields on Impact Receipts.
• Delete the pending request payload immediately after confirm/decline; expired requests are unavailable immediately and scheduled for automatic MongoDB deletion after the seven-day request window.
• Add an idempotent migration that preserves still-valid legacy verification links while stripping old verifier email/message/token fields from receipts and removing expired/orphaned pending requests.
• Add an operator migration/retention runbook.
• Add a privacy notice/link to verification request emails.
• Update Privacy Policy and Terms so the verifier-contact feature and user responsibility to provide third-party contact data are described consistently.

Privacy/security properties

• Raw verification tokens are never persisted.
• Pending verifier email/message/token hashes are stored separately with short retention instead of embedded indefinitely in career-proof records.
• Completed attestations do not retain verifier email, request message, token hash, or obsolete expiry.
• Trust-signal behavior remains tied to completed confirmation status.

Validation

This PR is initially draft for CI validation while #193 is still in flight. Before merge it must be refreshed onto the latest main, marked ready, and pass Backend, Frontend, and Security CI on that exact head with no unresolved blocker findings.

[mergemaven11]

Tuesday/Friday engineering sweep triage: keep open for #187, but do not merge. PR is still draft/non-mergeable, its exact head c084e9a03ef1456e2d794c32eb2df79923db6b80 has Backend CI failing (Frontend and Security passed), and it explicitly depends on/should follow the #186 remediation. Refresh after #193/#186 lands, resolve the Backend failure, mark ready, and rerun all required checks on the exact current head.

[mergemaven11]

Superseded by #206, which reapplies the verifier contact-data lifecycle remediation onto current protected main and includes fixes for the CI-discovered UTC/idempotence regressions. Closing this stale draft PR so #187 has one active remediation path.