[bigquery-firestore-export kit] A failed lifecycle task still reports a successful deploy

In the `bigquery-firestore-export` kit (`@firebase/bigquery-firestore-export`, on the `kits` branch), a lifecycle task that fails does not fail the deploy, so a rejected reconfiguration leaves no sign that anything went wrong.

### What happens

Clearing a `PARTITIONING_FIELD` that was previously set is not supported by the BigQuery Data Transfer API, and `kits/bigquery-firestore-export/src/dts.ts` throws for it deliberately. On a live project, `firebase deploy` still printed "Deploy complete!" and exited 0.

The failure stays inside the `upsertTransferConfig` task, which retried five times over 7m31s (30s, 60s, 120s, 240s backoff) before giving up at its `maxAttempts: 5` (`src/index.ts`). The transfer config and its Firestore document were left at the last good state.

Two things make it worse than a one-off:

- It is sticky. The empty value stays in `.env`, so every later deploy fails the same way, still silently, until the user restores a value that nothing tells them.
- The guard throws before any API call, so the error is deterministic and the five retries cannot help.

### Fix

Log a warning and return instead of throwing on a request that is known to be unsupported, which at least avoids five pointless retries. Surfacing lifecycle-task failures at deploy time needs a channel back to the CLI and is not fixable in the kit alone.

Start in kits/bigquery-firestore-export/src/dts.ts at the deliberate throw for clearing PARTITIONING_FIELD, then read src/index.ts to understand the upsertTransferConfig retry behavior. Run the described firebase deploy scenario and verify the unsupported request logs a warning, returns without five retries, and leaves the existing transfer configuration unchanged.

Written by the indexing model from the issue text.