feat(drive): trash/delete support, so mutations can be undone and cleaned up

[newhoggy]

Summary

There is no files.delete (or trash) anywhere in the Drive integration. It has been a standing deferral since #1574 and was restated in #1589, but it was abstract in both. Building and then live-testing the Sheets write surface gave it two concrete consequences.

Why it now has specific motivation

1. It is why CreatedValuesFailed has to exist.

drive sheets create --values creates a spreadsheet, then seeds its cells. If the seed fails after the create succeeds, there is no way to undo the create — so ADR-0073 §11 had to add a dedicated result variant that carries the new file id and says so:

Partially failed: created 'X' (1AbC…) in , but writing its values failed: … The spreadsheet exists and is empty — it cannot be rolled back automatically.

That variant is not a design preference. It exists purely because rollback is impossible, and it would collapse into an ordinary Failed if delete existed.

2. It makes the tool unable to clean up after itself.

While live-testing #1589 the tool created scratch spreadsheets in a test folder and then could not remove them — every other step of the test was automatable except teardown. Anyone scripting against drive create/upload/sheets create hits the same wall.

Why this needs care rather than a quick DELETE

Deletion is the one Drive mutation with no non-destructive dry run in the usual sense, and the API offers two materially different operations:

• files.trash — reversible, lands in the owner's trash, recoverable for 30 days.
• files.delete — permanent and immediate, and on a folder it removes every descendant.

Questions to settle

• Trash first, or both? Trash is recoverable and covers the cleanup use case; permanent delete is the sharp edge. Shipping only trash initially would be consistent with how this integration has staged risk so far.
• A new gate operation, or reuse an existing one? feat(drive): support the Google Sheets API for reading and writing spreadsheet cells #1589 introduced sheets-write specifically so an existing edit grant would not silently widen. The same argument applies with more force here: nobody who granted create on a folder thereby consented to deletion. A delete (and possibly separate trash) operation looks necessary.
• Folder recursion. drive move's shallow-folder limitation (ADR-0070 §8) is the precedent for drawing an explicit boundary rather than silently recursing.
• Does the CreatedValuesFailed path auto-roll-back once delete exists? Probably not by default — deleting on failure is itself a destructive act the operator did not ask for — but it becomes offerable.

Refs #1589, #1574, ADR-0073 §11, ADR-0070 §8