feat(sheets): extend the persisted batch primitive to structural spreadsheets.batchUpdate commands (batch-update covers values only)

What already exists, and what it does not cover

Two separate things are both called batching in gog, and only one of them is on Sheets.

gog sheets batch-update --data-json wraps spreadsheets.values.batchUpdate. It writes values to several ranges in one request. That is useful and shipped.

gog batch begin/list/show/end/abort/prune plus --batch=<id> on the mutating docs commands wraps the accumulate-then-submit pattern against documents.batchUpdate. Sheets has the same endpoint shape in spreadsheets.batchUpdate, and none of the structural gog sheets commands can reach it in a batch. gog batch begin takes --doc only.

The commands that are one call each

Every one of these is a spreadsheets.batchUpdate request type, and every one is its own process and its own API call on v0.39.0:

The cost

The documented Sheets quota is 60 write requests per minute per user per project (https://developers.google.com/workspace/sheets/api/limits), the same ceiling as Docs and Slides.

A formatting pass on a report sheet is not an exotic workload. Header row bold and filled, five column widths, a frozen header, a basic filter, three conditional-format rules, two number formats over separate ranges, a banded range, and two merges is 15 calls for a single tab. Repeat that across eight tabs and the run is 120 calls against a 60-per-minute ceiling, and half of it 429s. Batched, it is one spreadsheets.batchUpdate, far inside the request cap.

spreadsheets.batchUpdate is also the only way to get certain orderings right. Adding a chart that references a named range added in the same pass currently requires two calls with an implicit ordering the caller has to know about, where a single batch expresses it directly.

What a caller has to do today

Insert sleeps between calls, or drop to a Google API client library for the structural pass and keep gog for values. Splitting one spreadsheet's write path across two auth mechanisms is the outcome nobody wants.

Proposed surface

Same shape as the shipped Docs batch, so there is nothing new to learn:

gog batch begin --spreadsheet=<id> [--name=<label>]
gog sheets format            --batch=<id> ...
gog sheets conditional-format add --batch=<id> ...
gog sheets merge             --batch=<id> ...
gog sheets resize-columns    --batch=<id> ...
gog sheets chart add         --batch=<id> ...
gog batch end <id>

--dry-run, --continue-on-error, --auto-split and the revision lock behave as they do for Docs. spreadsheets.batchUpdate is atomic, so strict-atomic-by-default carries over unchanged.

Out of scope for a batch: get, read-format, notes, metadata, raw, export are reads; update and append go through the values endpoint rather than spreadsheets.batchUpdate and are already served by batch-update; create and copy create the file.

If gog batch begin grows one target flag per service the flags multiply, so a single --target <service>:<id> may age better than --doc / --presentation / --spreadsheet side by side. Either way the existing --doc should keep working.

Start with the existing gog batch Docs flow and the listed structural gog sheets commands, then trace how their requests are assembled and submitted. Define the spreadsheet target surface and batch behavior, implement coverage for the proposed mutating commands, and verify that batch end submits one atomic spreadsheets.batchUpdate request with the documented dry-run, error, splitting, and revision-lock behavior.