feat: user deletion functionality

[m0wer]

Description

Implements account deletion functionality as requested in #603. This adds a comprehensive soft-delete system that allows users to permanently delete their accounts while preserving system integrity.

Closes #603

Key Features:

• Soft delete with deletedAt timestamp to maintain referential integrity
• User data anonymization (nullifies email, pubkey, auth tokens, etc.)
• Optional content deletion that replaces posts/comments with [deleted] + hash
• Balance handling - users must withdraw or donate remaining sats/credits to rewards pool
• Proper authentication checks to reject deleted accounts
• UI integration in settings with confirmation flow
• Username hashing to prevent unique constraint issues while enabling potential future recovery

Technical Implementation:

• Added deletedAt field to User model with database migration
• Created deleteAccount GraphQL mutation with proper validation
• Modified authentication flow to check for deleted accounts
• Updated zap distribution to handle deleted users (credits go to rewards pool)
• Added daily cron job to collect earnings from deleted users and donate to rewards pool
• UI components now display [deleted] for anonymized users
• Comprehensive transaction handling to ensure data consistency

Decisions Made:

• Chose to allow balance donation to rewards pool if user insists on deletion
• Username gets hashed with deletion timestamp rather than complete removal (enables potential recovery)
• Content hashing uses SHA256 for anonymization while maintaining uniqueness
• Deleted user content can still be zapped (credits go to rewards pool automatically)
• Earnings from deleted users are collected daily and donated to rewards pool

Screenshots

Additional Context

Several implementation decisions were made that weren't explicitly defined in the original issue:

1. Balance Handling: Added option to donate remaining balance to rewards pool rather than requiring complete withdrawal
2. Username Strategy: Hash username with deletion timestamp instead of complete removal - could enable recovery
3. Zap Handling: Zaps to deleted user content automatically go to rewards pool via modified distribution logic
4. Content Anonymization: Uses SHA256 hashes for both usernames and content to maintain uniqueness while ensuring privacy
5. Earnings Collection: Added daily cron job to collect any earnings that accrue to deleted users and donate to rewards pool

The authentication flow required updates in multiple places (NextAuth callbacks, SSR Apollo client, etc.) to properly handle deleted accounts across the application.

Checklist

Are your changes backwards compatible? Please answer below:
Yes, fully backwards compatible. Existing users are unaffected, and the deletedAt field is nullable. No breaking changes to existing APIs or database schema.

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
7/10 - Tested core deletion flow, authentication rejection, UI display, and balance handling. Would benefit from additional testing of edge cases around zap distribution and the daily earnings collection job in production environment.

For frontend changes: Tested on mobile, light and dark mode? Please answer below:
Yes - The settings UI changes had mobile and dark mode testing. The [deleted] user display in comments/posts already worked.

Did you introduce any new environment variables? If so, call them out explicitly here:
No new environment variables introduced. Uses existing USER_ID.sn constant for system donations.

[m0wer]

BTW the lint error is unfixable! (take it as a challenge) It looks like the linter gets confused with the ternary operator inside the nested JSX structure. If there's no way to fix it, we can just disable the check for those lines.