FEATURE REQUEST: Update Supabase key system from legacy

### Is your feature request related to a problem?

- [x] Yes, it is related to a problem

### Describe the feature you'd like

> This issue was fully identified and analyzed by myself. Claude was only used to assist with writing in English.

## 🌟 Feature Description

Currently, NeuroTrack uses Supabase's legacy JWT-based API keys (`anon key` and `service_role key`) for all client-server communication. Supabase [announced in September 2024](https://github.com/orgs/supabase/discussions/29260) a migration to a new key system — **publishable keys** (`sb_publishable_...`) and **secret keys** (`sb_secret_...`). As of November 1, 2025, new and restored Supabase projects no longer include legacy keys, and **legacy keys are scheduled for permanent deletion in late 2026**. This issue tracks the work needed to migrate NeuroTrack to the new key system.

## 🔍 Problem Statement

The legacy JWT-based keys have several known shortcomings that the new system addresses:

- **No independent key rotation without downtime** — rotating legacy keys required service interruption
- **Mobile app deployment lag** — forced key rotation could cause days-to-weeks of downtime for users on older app versions
- **Insecure defaults** — legacy JWTs had 10-year expiry, were large, hard to parse, and prone to insecure logging
- **No granular revocation** — compromised keys couldn't be individually revoked

Beyond the general migration, NeuroTrack has a **code-level breaking change** that goes beyond simple renaming:

1. **`patient/lib/repository/supabase_assessments_repository.dart`** — The anon key is manually passed as `Authorization: Bearer $jwtToken` when invoking the Edge Function. New publishable keys are **not JWTs**, so this pattern will fail. The fix is to remove the manual header and rely on the SDK's automatic auth token injection.

2. **`supabase/functions/evaluate-assessments/index.ts`** — The Edge Function reads `SUPABASE_ANON_KEY` from auto-injected environment variables. After migration, this env var [may not auto-update](https://github.com/supabase/supabase/issues/37648), and JWT verification at the Edge Function level needs to be reviewed (new keys cannot pass JWT verification).

3. **Environment variables and documentation** — `.env.example` files in `patient/`, `therapist/`, and `supabase/scripts/`, as well as `README.md`, all reference legacy key names.

## 🎯 Expected Outcome

- Replace all `SUPABASE_ANON_KEY` references with `SUPABASE_PUBLISHABLE_KEY` (or equivalent) across Flutter apps, Edge Functions, and environment configs
- Replace `SUPABASE_KEY` (service role) references with `SUPABASE_SECRET_KEY` in backend scripts
- **Refactor** `supabase_assessments_repository.dart` to stop manually injecting the API key as a Bearer token — instead, let the Supabase SDK handle auth headers automatically
- **Review** Edge Function JWT verification strategy and update deployment config if needed (`--no-verify-jwt` or user-JWT-based auth)
- Update `README.md` setup instructions to reflect the new key names

## 📷 Screenshots and Design Ideas

**Affected files:**

| File | Change Type |
|---|---|
| `patient/.env.example` | Rename variable |
| `therapist/.env.example` | Rename variable |
| `patient/lib/main.dart` | Update env var name |
| `therapist/lib/main.dart` | Update env var name |
| `patient/lib/repository/supabase_assessments_repository.dart` | **Code refactor** — remove manual Bearer token |
| `supabase/functions/evaluate-assessments/index.ts` | Update env var + review JWT verification |
| `supabase/scripts/.env.example` | Rename variable |
| `supabase/scripts/seed_assessments.js` | Update env var name |
| `README.md` | Update documentation |

## 📋 Additional Context

There is an ongoing discussion in the community channel about **removing cloud dependencies** from the project. The AOSSIE group is moving toward a direction where sensitive data should not reside on external servers, with discussions leaning toward a local database approach. If the decision is made to drop Supabase Cloud in favor of a local database solution, this migration may become unnecessary — the project could continue using the legacy keys until the cloud dependency is removed entirely. This issue should be considered in the context of that broader architectural decision.

**References:**
- [Upcoming changes to Supabase API Keys (Discussion #29260)](https://github.com/orgs/supabase/discussions/29260)
- [Edge Function env var issue after migration (#37648)](https://github.com/supabase/supabase/issues/37648)
- [Community discussion on new API keys (#40300)](https://github.com/orgs/supabase/discussions/40300)

### Record

- [x] I agree to follow this project's Code of Conduct
- [x] I want to work on implementing this feature