Fix supporter wallet address exposure and ProfileReport IP retention

[meshackyaro]

Summary

• [Backend] contribution-received email subject exposes supporter's full Stellar wallet address — privacy concern #869 — contribution-received email subject exposed the supporter's full 56-character Stellar wallet address (email subjects are indexed/cached by providers and shown in push notification previews). The subject now shows a truncated address (GABCDE...UVWX); the full address is still in the email body.
• [Privacy] ProfileReport model permanently stores IP addresses but privacy policy states IPs are not stored long-term #870 — ProfileReport.reporterIp was stored indefinitely, contradicting the privacy policy's claim that IP addresses are "not stored long-term". Added an expiresAt field (90 days from creation) and a daily scheduled job (ip-retention-purge.ts, following the existing weekly-digest.ts pattern) that nulls out reporterIp once expired. The report itself (reason/details) is kept for moderation history. Updated the privacy policy copy to accurately describe this retention window.

Notes

• Frontend CI is currently failing on main independent of this PR (pre-existing react/no-unescaped-entities lint errors in terms/page.tsx and unrelated lines of privacy/page.tsx) — confirmed via gh run list across the last several merges. This PR's own edits to privacy/page.tsx don't introduce any new lint errors; fixing the pre-existing repo-wide issue is out of scope for [Backend] contribution-received email subject exposes supporter's full Stellar wallet address — privacy concern #869/[Privacy] ProfileReport model permanently stores IP addresses but privacy policy states IPs are not stored long-term #870.
• Backend CI (tests, lint, build, Prisma migration + drift check) was fully validated locally against the exact CI environment (Postgres 16, Node 22) before opening this PR.

Closes #869, Closes #870

Test plan

• npm run test (backend) — all suites pass except pre-existing, network-dependent failures reproduced identically on a clean upstream/main checkout (Horizon/Redis-dependent tests unreachable in a sandboxed environment)
• New unit tests for the truncated subject and the IP purge job
• npx prisma migrate deploy + CI's exact prisma migrate diff drift check — no drift
• npm run build (backend) — clean
• npm run lint (backend) — 0 errors (pre-existing warnings only)

[drips-wave]

@meshackyaro 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

[meshackyaro]

CI status note

All four CI checks on this PR are red, but none of the failures are caused by this PR — they're pre-existing, repo-wide issues on main:

• Backend CI: fails on a flaky test in verify-transaction.test.ts ("known valid transaction returns true (live testnet)") that depends on a specific transaction still existing on Stellar testnet. This has been failing on every main push since at least 2026-07-25 (e.g. runs for fix: add GitHub fetch timeout and escape user input in HTML emails #890, Fix issues #886, #887, #888, #889: Multiple fixes across backend, fro… #891, fix(backend): address transaction fraud, OOM sort, TOML passphrase, a… #892, fix: Redis cache, BullMQ webhook queue, pg_trgm migration, Prisma pool tuning (#775 #776 #777 #778) #893, fix: resolve notification email, asset filter, metrics, and recurring… #894). I reproduced the exact same pass/fail/cancelled counts (105/12/15) on a clean upstream/main checkout with no changes of mine.
• Frontend CI: fails on pre-existing react/no-unescaped-entities lint errors in terms/page.tsx and unrelated lines of privacy/page.tsx (raw quotes not escaped as "), also failing on every recent main push.
• E2E (Playwright) / Lighthouse CI: also red on recent main pushes independent of this PR.

This PR's own changes were fully validated locally against the CI environment (Postgres 16, Node 22): backend tests, lint (0 errors), build, and prisma migrate diff drift check all pass. The line I added to privacy/page.tsx doesn't introduce any new lint errors — I checked the exact escaped/unescaped output.

Happy to open a separate PR to stabilize these pre-existing CI issues if that's useful, but keeping this PR scoped to #869 and #870 as assigned.