firestore-vector-search: OpenAI vector index is 512 dimensions while the vectors are 1536, in both extension and kit

With `EMBEDDING_PROVIDER=openai`, the Firestore vector index does not cover the vectors that get written, so `findNearest` cannot use it. Both the extension and the kit do this, identically.

| | Extension | Kit |
|---|---|---|
| Index dimension | 512 (`getDimension()`, [`functions/src/config.ts`](https://github.com/GoogleCloudPlatform/firebase-extensions/blob/main/firestore-vector-search/functions/src/config.ts)) | 512 (`dimensionFor()`, `kits/firestore-vector-search/src/export-config.ts`) |
| Model | `text-embedding-ada-002` | `text-embedding-ada-002` |
| Vector written | 1536 | 1536 |

Each codebase contradicts itself the same way: the value fed to `createIndex` says 512, while the OpenAI client is built with `dimension: 1536` and ada-002 returns 1536.

The vectors store fine, Firestore's limit is 2048, but querying them fails:

```
9 FAILED_PRECONDITION: Missing vector index configuration. Please create the required
index with the following gcloud command: gcloud firestore indexes composite create
--project= --collection-group= --query-scope=COLLECTION
--field-config=vector-config='{"dimension":"1536","flat": "{}"}',field-path=embedding
```

So the provider embeds correctly and is unqueryable through `queryCallable`, `queryOnWrite` or any direct `findNearest`, unless the user creates a 1536-dimension index by hand. Verified live on a deployed instance.

## Fixing it

`dimensionFor("openai")` / `getDimension()` should return 1536 so the index matches what ada-002 produces. Because both codebases are affected equally, fixing only the kit would introduce a parity divergence, so this wants fixing in both, or a deliberate decision to lead with one.

Two things any fix has to handle:

- **Existing 512 indexes are not replaced.** `createIndex` decides an index already exists by matching the collection name and the field path only, never the dimension, so an instance that already created the 512 index keeps it and creation is skipped. A fix needs a migration note telling users to delete the old index first, or the existence check has to compare dimensions too. Note the second option would also silently rebuild any drifted index on every install.
- **The extension persists the dimension.** The extension writes `dimension` into its metadata document at `_/index` and re-backfills when `metadata.dimension !== config.dimension`, so changing the value there triggers a full re-embed of the collection, at cost. The kit has no such metadata document today, so it is only a concern for the extension and for any future kit work that restores that gating (see §9d in the ledger).

`multimodal` has the same shape of self-contradiction (index 512, client 1408) and is covered by #3135.

Related: #3096 restored the ada-002 model, #3105 raised this as a parity question (closed, the kit is in parity), #3163 attempted a kit-only fix (closed as out of parity).

Start with functions/src/config.ts and kits/firestore-vector-search/src/export-config.ts, then trace createIndex and the extension metadata at _/index. Confirm how existing indexes are detected and how a dimension change triggers extension re-embedding. Done means both codebases consistently represent the 1536-dimensional OpenAI vectors and the existing 512-index migration behavior is explicitly handled.

Written by the indexing model from the issue text.