fix(bigquery-firestore-export): soft failures throw and retry-storm

[cabljac]

Originally filed as "soft failures throw and retry-storm" from the #2974 parity analysis (bigquery-firestore-export §7a-7c, §8). The state has moved, so reframing.

Current state

• processMessages now runs with retry: false (6a9d53d), matching the extension, so the pub/sub half of §8 no longer storms.
• fix(bigquery-firestore-export): stop retrying deploy-time misconfigurations #2983 (open) introduces PermanentConfigurationError for the upsertTransferConfig task: permanent misconfigurations log and return instead of retrying; transient errors still retry.
• bigquery-firestore-export: clearing PARTITIONING_FIELD is blocked but the DTS API allows it #2985 tracks the partitioning-field guard (§7b) separately.

Possible remaining problem

retry: false may trade the storm for silent loss: a transient failure (Firestore blip, timeout) acks and drops the completion notification, and that run's output never reaches Firestore. The extension appears to have the same flaw, so this is parity, but arguably parity with a flaw. With retry: true, v2 pub/sub retries go through Eventarc with exponential backoff (10s to 600s, up to 24h), so retries look bounded rather than stormy - the storm concern seems to only apply to permanent errors, which the #2983 pattern addresses.

Proposed plan (needs agreement, since it goes beyond parity)

1. Land fix(bigquery-firestore-export): write run output to deterministic ids #2963 (deterministic run-output ids) so redelivery cannot duplicate docs.
2. Extend the fix(bigquery-firestore-export): stop retrying deploy-time misconfigurations #2983 classification to handleMessagePublished (non-associated config, malformed payload → log and return).
3. Then flip processMessages to retry: true. Order matters.
4. Sweep the remaining handler throw sites and classify permanent vs transient.

The lost setProcessingState visibility is out of scope here, tracked in #3035.

Depends on: #2983, #2963, #2985. Parity ledger: #2974.