fix(bigquery-firestore-export): helper crashes on real BigQuery TIME values

[cabljac]

The kit's value conversion converts BigQuery temporal types via Timestamp.fromDate(new Date(value)), but a real TIME value (BigQuery.time("10:30:00").value === "10:30:00") makes new Date("10:30:00") invalid and Timestamp.fromDate throws Value for argument "seconds" is not a valid integer. - so a scheduled query whose results include a TIME column crashes the run. Probe-verified during review of #3056 (IzaakGough); that PR pins the throwing behavior with a test so this fix flips it deliberately. Decide the correct representation (probably keep the raw string, matching what the extension stored). Ledger: #2974.

[IzaakGough]

I went looking for what the extension stored for a TIME column, and it turns out it throws on the same line the kit does.

Both sides route BigQueryTime through the same branch:

• extension v0.2.2, functions/src/helper.ts:365-377: shouldConvertToTimestamp matches BigQueryTime, then Timestamp.fromDate(new Date(value.value))
• kit, src/helper.ts:180-188: same four types, same Timestamp.fromDate(new Date(row.value))

BigQuery.time("10:30:00").value is "10:30:00", so new Date(...) is Invalid Date and both throw Value for argument "seconds" is not a valid integer. Probed from the kit's tree:

ctor: BigQueryTime value: "10:30:00"
THROW: Value for argument "seconds" is not a valid integer.

Nothing in the extension returns .value unchanged for a temporal type. Geography is the only type it does that for. The extension's test at functions/__tests__/helper.test.ts:644 uses new BigQueryTime('1970-01-01T10:30:00Z'), which is not a value BigQuery produces, so it converts cleanly and the suite never reaches the crash.

That makes keeping the raw string a new behaviour in the kit rather than a restored one. Since parity is the goal, is that the change we want? Options as I see them:

1. Leave the kit matching the extension and keep the test from test(bigquery-firestore-export): port legacy unit coverage into the kit #3056 that pins the throw.
2. Fix it in both, so a migrated deploy does not shift shape.
3. Fix the kit only and document it, alongside the array vs "0"/"1" map divergence this function already has.

Happy to take whichever. Worth saying I verified this by reading both implementations and probing the value conversion locally, not against a live scheduled query, though given the two identical code paths I do not think a real run could ever have stored a TIME value.