decision(firestore-vector-search): OpenAI vector index is 512 dimensions while the vectors are 1536

[CorieW]

Follow-up from #3096 (review). #3029 decided the embedding model; it did not decide the index dimension, and once it closes nothing tracks this. Today it lives only in the kit's README.

The problem

With EMBEDDING_PROVIDER: openai, the vector index the kit creates does not cover the vectors it writes, so findNearest cannot use it.

	Value	Source
Index dimension	512	dimensionFor() in src/export-config.ts:90, passed to createIndex
Vector written	1536	text-embedding-ada-002 native size, src/embeddings/client/text/open_ai.ts

This is inherited from the extension, deliberately. The extension has two dimension tables that disagree: getDimension() returns 512 for openai while OpenAIEmbedClient is constructed with dimension: 1536 and ada-002 returns 1536. #3096 restored the extension's model, so the kit now reproduces the mismatch exactly (parity ledger #2974, firestore-vector-search §1 and §2).

Verified live on a deployed instance. 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=<project> --collection-group=<collection> --query-scope=COLLECTION
--field-config=vector-config='{"dimension":"1536","flat": "{}"}',field-path=embedding

So EMBEDDING_PROVIDER: openai embeds correctly and is unqueryable through queryCallable, queryOnWrite, or any direct findNearest, unless the user creates a 1536-dimension index by hand.

Options

1. dimensionFor("openai") returns 1536. The index then matches what ada-002 actually produces and the provider works end to end. Diverges from the extension's 512, but that 512 never matched its own client, so this repairs a self-contradiction rather than changing a working behaviour.
2. Pin dimensions: 512 on the OpenAI request. ada-002 does not support the dimensions parameter, so this means moving to text-embedding-3-small — which is what the kit did before fix(firestore-vector-search): restore the extension's embedding defaults #3096, and what decision(firestore-vector-search): embedding model and dimension defaults #3029 decided against.
3. Leave it and keep documenting it. Full parity, including the bug. The default provider is unaffected; anyone on openai gets a README note and a manual index.

Option 1 looks right to me, but it is a parity divergence, so it needs the same decision treatment #3029 got.

Also worth folding in

createIndex decides an index already exists by matching the collection name and the field path only — it never compares the dimension (src/queries/setup.ts:49-56). Whichever option wins, an instance that already created a 512-dimension index keeps it: the check sees embedding and skips. Any fix needs a migration note telling users to delete the old index first, or the existence check needs to compare dimensions too.