Compare BigQuery streaming inserts versus Storage Write API and implement the correct path for high-throughput ingestion

Verified steps

1. Legacy streaming inserts (tabledata.insertAll): send JSON rows via the REST API; rows are available for queries within seconds but appear in a streaming buffer that incurs separate storage billing and is not reflected in INFORMATION_SCHEMA row counts immediately.
2. Storage Write API (v1/v2 BigQuery Write API): use the committed stream type for at-least-once delivery or the pending stream type for exactly-once delivery; rows are written in binary protobuf format which is more efficient than JSON.
3. For exactly-once with the pending stream: write row batches with offset sequences, then call FinalizeWriteStream followed by BatchCommitWriteStreams; rows become visible only after commit, providing transactional guarantees.
4. Use the default stream of the Storage Write API for at-least-once high-throughput ingestion without stream management; it behaves similarly to legacy streaming inserts but uses the more efficient binary protocol.
5. Choose client library (Python, Java, Go) with the BigQuery Storage Write API client; avoid constructing raw gRPC calls manually as the client handles reconnection and offset tracking.
6. Legacy streaming inserts charge per GB inserted; Storage Write API charges per GB for data written beyond the free monthly quota; compare unit costs at your projected volume before selecting.