cold-store-reaper: 700 GB/day upload hard stop and 3 TiB budget are reported by status but never enforced in upload / put-backup #938

Finding

cold-store-reaper's 700 GB/day upload hard stop and 3 TiB project budget are reported but never enforced. status computes hard_stop_ok / within_budget, but no upload path checks them before sending bytes, so the "hard stop" stops nothing.

Found by the pr-diff-review job reviewing PR #923 (cold-store-reaper v1) and PR #929 (v2), 2026-10-25.

Evidence

• pkgs/cold-store-reaper/schema.sql:56-57 seeds the guardrails: project_budget_bytes = 3298534883328 (3 TiB) and daily_upload_hard_stop_bytes = 700000000000 (700 GB). PR cold-store-reaper v1: Google Drive cold-store CLI (pack / resumable upload+verify / range fetch) #923's body describes the manifest as holding the "700 GB/day upload hard stop".
• On current main (92d0c6ee), pkgs/cold-store-reaper/cold_store.py:
  • upload() (line 558) goes straight from the bundle-state check to _resumable_upload(...) — no read of the transfer ledger, daily_upload_hard_stop_bytes, or project_budget_bytes.
  • put_backup() (line 672, added by PR cold-store-reaper v2: D1 manifest sync, DB-backup class, rehydrator Worker #929) likewise uploads via _resumable_upload(...) (line ~693) with no guardrail check, then writes its backup-upload ledger row afterwards.
  • The only consumers of the two meta values are in status_data() (lines 888-901), which derives hard_stop_ok and within_budget for display. grep -n hard_stop cold_store.py shows no other use.
• So a loop or operator error that uploads past 700 GB in 24h (Google Drive's own daily upload ceiling — hitting it mid-run strands resumable sessions) or past the 3 TiB project budget is stopped by nothing in the tool that owns those numbers.

Why it matters

The design's cost/quota guardrail exists only as a status readout. The reaper is meant to run unattended over very large archives; an unenforced hard stop converts a designed safety limit into a false sense of security, and the first notice would be Drive quota failures or budget overrun discovered after the fact.

Acceptance criteria

• upload and put-backup refuse to start (clear ColdStoreError naming the limit and the current 24h/project totals) when the transfer would cross daily_upload_hard_stop_bytes (last-24h uploads + this transfer) or project_budget_bytes (verified cold bytes + this transfer).
• The check uses the same ledger/meta accounting as status_data so status and enforcement can never disagree.
• Tests (fake-Drive, following the existing test style) cover: upload refused at/over the daily stop, upload allowed under it, put-backup refused likewise.
• README's description of the hard stop / budget matches the enforced behavior.

— filed by the pr-diff-review job (PRs #923, #929); triage via the repo-health queue pilot.