decision(firestore-bigquery-export): DATASET_LOCATION is immutable in the extension but silently ignored on change in the kit

[cabljac]

Problem

The extension declares DATASET_LOCATION with immutable: true (firestore-bigquery-export/extension.yaml), so a reconfigure cannot change it. firebase-functions/params has no immutability, so the kit (kits/firestore-bigquery-export/src/config.ts:236) accepts a new value on any redeploy.

What happens today when the value changes on an existing install:

• The tracker's initializeDataset finds the dataset by id and skips creation (firestore-bigquery-change-tracker/src/bigquery/index.ts:308), so the dataset stays in its original location. The new value is silently ignored. Nothing in the tracker or the kit runs a query job with the configured location, so nothing fails.
• If DATASET_ID changes at the same time, a new dataset is created in the new location and the old one is left behind with its tables and view, same as the extension when the dataset id changes.

So the divergence is: the extension refuses the edit, the kit accepts it and does nothing. Not data loss, but a config that lies.

Options

1. Guard in the lifecycle task: read the existing dataset's location and log an error (or fail setupBigQuerySync) when it differs from DATASET_LOCATION.
2. Notes entry only (docs(kits): write the Notes entries for accepted divergences #3035): document that DATASET_LOCATION only applies when the dataset is first created, and that moving a dataset means a new DATASET_ID plus a backfill.

Recommend 1 plus 2: the guard is a few lines and turns a silent no-op into a visible one.

Cosmetic, same param family

The kit's DATABASE_REGION select offers asia-southeast3 (config.ts:177), which the extension's extension.yaml does not list. Harmless (it is a real Firestore location), but a divergence to drop or note when this is picked up.

Parity ledger: #2974.