fix(firestore-bigquery-export): take the extension's yes/no values for snapshot syntax and old data

[cabljac]

USE_NEW_SNAPSHOT_QUERY_SYNTAX and EXCLUDE_OLD_DATA were defineBoolean params, so only the literal true enabled them and the README told users to rewrite yes to true after a migration. The extension defines both as yes / no selects (extension.yaml:575, :589), and the migration exports those values verbatim, so a migrated .env silently left both off. Agreed direction in extension chat: stay with the closest match to the extension so users enter nothing during migration, and do better for new kits or new params.

Both are now defineString with a select({ Yes: "yes", No: "no" }) input and default no, mirroring the extension's labels, values, and default, and configFromEnv maps them with a yesNo helper. Only yes enables, compared after trimming and lowercasing so the select label Yes and stray whitespace still work; no and anything else, true included, read as off. firebase-tools copies .env values verbatim without checking them against the select, which is why the label and whitespace are forgiven; true is not, since the kit has no users who could have written it and the extension's select never emits it. WILDCARD_IDS stays defineBoolean: the extension's select there is true / false, which BooleanParam already parses. The README's "Boolean settings use true / false" difference section is removed since the difference is gone.

Audit of the rest of the kit's params: no other boolean-shaped extension param exists. delete-user-data has the same shape on ENABLE_AUTO_DISCOVERY and is not part of this stack.

Tests: four new cases in config.test.ts cover the unset value, yes, the Yes and whitespace spellings, and no / true. The defineString mock now matches the real StringParam (process.env[name] || "", never the declared default, which only the CLI prompt consults), and the one test that relied on a default now stubs the env var the way the CLI populates it. 100 tests and tsc pass at the top of the stack. Not verified against a live migration export.

Part of #3031.

[gemini-code-assist]

Code Review

This pull request reverts the configuration parameters USE_NEW_SNAPSHOT_QUERY_SYNTAX and EXCLUDE_OLD_DATA to accept the extension's original yes/no string values instead of booleans, ensuring compatibility with existing configurations. The feedback suggests trimming whitespace in the yesNo helper function to prevent potential issues with leading or trailing spaces in environment variables.

[IzaakGough]

Change itself looks right: the extension declares both params as yes / no selects and compares === "yes" at runtime, and WILDCARD_IDS correctly stays true / false. Two low-severity notes inline, neither blocking.