Vexa API key stored without documented rotation policy - bot integration key leak gives attacker control over meeting bots

## Problem

The `VEXA_API_KEY` is stored as an environment variable (shown in
`.env.example`) with no documentation on:
- What the Vexa API key authorizes (e.g. whether it can create unlimited bots
that consume transcription minutes).
- How to detect unauthorized usage of the key.
- How to rotate the key if it is leaked.
- Whether the key is scoped to specific meetings or is a global account key.

If the key is leaked (e.g. accidentally committed to the repository or exposed
in server logs), an attacker can start Vexa bots for any meeting, consuming
the account's transcription quota or incurring charges without limit.

## Impact

- Unauthorized meeting bot creation and quota exhaustion.
- Potential exposure of meeting invites and transcription data if bots are
started for meetings the attacker does not own.
- Financial cost from unauthorized usage of a paid transcription service.

## Suggested Fix

1. Document in `BACKEND.md` the minimum required Vexa API permissions and
how to create a restricted-scope key if the Vexa API supports it.
2. Add usage monitoring (Vexa dashboard alerts or webhook notifications) to
detect unexpected bot activity.
3. Document a key rotation procedure in `BACKEND.md`.
4. Store the Vexa key only in Supabase Edge Function secrets, never in the
Flutter client or any client-accessible configuration.
5. Add `.env` to `.gitignore` (verify it is not currently tracked) to prevent
accidental commits.