Feature: Add secure account recovery, session management, and account deletion

## Summary

Complete the authentication lifecycle with email verification, password recovery, session/device management, credential changes, and a guarded account-deletion workflow.

## Problem / Opportunity

TaskNexus currently supports registration, sign-in, and sign-out through Supabase Auth, but users have no in-app path to recover a forgotten password, verify or change their email, inspect active sessions, revoke a lost device, or permanently close their account. These gaps can lock users out or leave them without control over account security and retained task data.

## Proposed Feature

Add an Account & Security area backed by Supabase Auth that supports verified deep-link recovery across iOS, Android, and web. Show active sessions where the platform APIs permit it, allow revocation and password/email changes with appropriate reauthentication, and provide a deliberate account-deletion flow that handles owned data safely.

## Scope

- Add forgot-password, recovery-link handling, set-new-password, resend-verification, email-change, and password-change flows.
- Configure and document Expo Router deep links and approved Supabase redirect URLs for native and web environments.
- Add an Account & Security screen for identity status and session controls.
- Define server-enforced cleanup or retention behavior for tasks and related user-owned records during deletion.
- Add rate-limit feedback, expired/used-link states, generic privacy-preserving messages, and audit-safe logging.
- Cover keyboard, screen-reader, large-text, loading, offline, and error behavior.
- Document local development, production redirect configuration, and security test cases.

## Acceptance Criteria

- [ ] A signed-out user can request a password-reset email without the UI revealing whether an address is registered.
- [ ] Valid recovery links open the correct TaskNexus route on iOS, Android, and web and allow a compliant new password to be set.
- [ ] Expired, malformed, reused, and wrong-environment links produce safe, actionable recovery options.
- [ ] Registration and email changes expose verification state and allow rate-limited verification-email resend.
- [ ] Sensitive email or password changes require a documented recent-authentication check.
- [ ] Users can view meaningful active-session information supported by Supabase and revoke other sessions without terminating the current flow unexpectedly.
- [ ] Account deletion requires explicit reauthentication and confirmation, then applies a documented policy to tasks and all user-owned data.
- [ ] After revocation or deletion, stale clients lose protected access and realtime subscriptions without leaking cached data into another session.
- [ ] Auth controls, validation errors, status changes, and confirmations are accessible by keyboard and screen reader.
- [ ] Tests cover deep-link routing, recovery state transitions, token failure cases, session revocation, RLS after deletion, and cross-user isolation.
- [ ] README or dedicated security documentation explains redirect configuration, lifecycle behavior, privacy safeguards, and manual verification steps.

## Non-Goals

- Social login or enterprise single sign-on.
- Multi-factor authentication in the initial implementation.
- Administrator access to user credentials or recovery tokens.
- Custom email-delivery infrastructure beyond supported Supabase configuration.

## Dependencies / Risks

- Native and web recovery require environment-specific redirect allowlists and reliable deep-link configuration.
- Supabase client APIs may not expose every session-management capability; privileged operations must remain server-side.
- Account deletion can be irreversible and must account for future shared workspace, history, backup, and metadata relationships.
- Auth event handling in TaskContext must prevent stale tasks from flashing during account transitions.

## Open Questions

- Which recent-authentication window should protect credential changes and deletion?
- Should account deletion be immediate or enter a short recoverable grace period?
- What session metadata can be shown consistently without collecting additional device-identifying data?
- Should multi-factor authentication be tracked as a separate follow-up after this lifecycle foundation?