decision(firestore-vector-search): status field shape, nested per-instance vs flat

[cabljac]

The extension wrote a nested, per-process status via @invertase/firebase-extension-utilities:

status.<EXT_INSTANCE_ID> = { state, startTime, updateTime, completeTime, createTime }
status.textQuery = { ... }

with states PROCESSING | COMPLETED | ERROR | BACKFILLED | FAILED_BACKFILL, two writes per document.

The kit writes a flat field, one write per document:

status = { state: "COMPLETED" }
status = { state: "ERROR", message }

No PROCESSING, no timestamps, no BACKFILLED / FAILED_BACKFILL.

Any consumer reading status.<instanceId>.state breaks on migration, and documents embedded by the extension carry a status the kit's terminal-state guard does not recognise until the field is flattened. #3092 (#3011) restores the skip-on-terminal-state rule against the flat shape and explicitly leaves the shape itself out of scope.

Decide one of:

• Parity: restore the nested per-instance shape and the full state set, so extension consumers and already-embedded documents carry over unchanged.
• Keep flat: document the shape change and the migration step (flatten status.<instanceId> to status) in the kit README and the Notes entries (docs(kits): write the Notes entries for accepted divergences #3035).

Parity ledger: #2974, firestore-vector-search §6.