Storage: recover safely from interrupted uploads and fork copies that hold reservations #193

Part of the post-launch billing hardening (follows #139). This one is in the repos service.

A crashed upload or fork copy leaves repos.storage_reserved_bytes and/or a storage_copy_locks row behind (repos migration 0021). RESERVE then refuses pushes until someone clears them by hand.

Build safe staff tooling:

• List stale reservations and locks, with their age and the operation behind each.
• Inspect the upstream repository's state.
• Release only what is provably abandoned, and write an audit row when you do. Never expire them blindly.
• Add conformance tests in conformance/public-storage.test.mjs, and a sudo view or an admin RPC.

Also reconcile the measured stored_bytes against the provider's actual storage for a sample of repositories, and report any drift.

Billing safety rules (non-negotiable)

Billing has been live on Stripe since 2026-10-15 and takes real money from real customers.

• Never run fixtures, seeds or the sandbox harness against the production Stripe account. Test only with the separate Stripe sandbox key and a local billing Worker (target/billing-audit). Its .dev.vars loads automatically, and --env-file does not bind secrets. The harness is scripts/ops/billing-sandbox.mjs (phases: protocol, seed, run, cleanup, lifecycle, enterprise, complimentary). Ask the owner for the sandbox key's location.
• Never print or commit secrets. Writing Worker secrets is the owner's job: hand them the exact command, in Git Bash syntax with single quotes and forward slashes.
• Any live charge, refund or change to a Stripe object needs the owner's explicit OK for that specific action.
• Pushing to main deploys production, migrations first and then the Workers. Every migration must be safe against the code already running.
• Billing's own API requests stay pinned to Stripe API 2025-02-24.acacia. The live webhook's events are listed in services/billing/src/webhooks.rs EVENTS.
• The owner's billing audit notes (docs/audits/2026-10-14-billing.md, local and ignored by Git) hold the "LIVE" section and the remaining launch gates. Ask for them if you don't have them.

Validation for every change

cargo test -p g1t-billing --lib (and -p g1t-repos for storage); cargo check of the workspace and of the changed services for wasm32-unknown-unknown; node --test --test-isolation=none conformance/*.test.mjs; the TypeScript checks and tests for anything touching apps/ or packages/; npm run test:deploy; build the actual billing Worker before running sandbox phases; git diff --check; and inspect what is staged for secrets and artifacts. Get an independent review of money-path changes before they are pushed. Report what was verified live and what was verified only in the sandbox.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.