Schema & robustness hardening: contents immutability triggers (v21) + #114 cluster

[mbertschler]

Final hardening PR of the adversarial-audit follow-up. Schema defense-in-depth (#113) plus the robustness cluster (#114). Every change is additive or a refusal; nothing relaxes an existing guarantee.

Addresses #113
Addresses #114

Schema change (v21)

New migration migrateV20ToV21 (additive; no existing migration edited) installs two triggers on contents, restoring the schema-level immutability the AGENTS.md append-only contract implies and that the v13→v14 reshape dropped along with files_blake3_immutable:

• contents_no_update — BEFORE UPDATE ON contents → RAISE(ABORT, …)
• contents_no_delete — BEFORE DELETE ON contents → RAISE(ABORT, …)

store/schema.sql regenerated via go test ./store -update-schema; TestSchemaSnapshot green. Defense-in-depth: the auditor confirmed there is no UPDATE/DELETE path on contents today.

#113 — index/migration integrity

Item	Disposition
12a contents immutability trigger	Landed — v21 triggers above.
12b v14 backfill same-hash-different-size guard	N/A in v14 — cannot edit the v14 migration (immutable-migration rule). The runtime equivalent (item 2 below) is degenerate post-v14.
12c migration test shapes	Landed — TestMigrateV18ChainToV21 drives a populated v18 fixture (contents, files, remote_objects, destination_run_ids) through v19→v21, asserts the offload-substrate rows survive (verify_method NULL-backfilled, remote_objects fingerprint intact), and asserts the contents triggers ABORT an UPDATE and a DELETE.

Skipped with note — contents/files blake3↔size consistency check (db check): post-v14, contents.blake3 is UNIQUE and files reference content_id (not blake3/size), so a blake3→size disagreement is unrepresentable by construction; a runtime check would have nothing to find. The v21 immutability trigger plus the merged #107 stat-after-hash fix already prevent new occurrences. Did not force a degenerate check in; happy to file a follow-up if a non-degenerate framing is wanted.

#114 — robustness cluster

All five items in scope landed (each a focused change with a test):

• Run-gate asymmetry — added 'offload' to the blocking sets of BeginSyncRunIfClear and BeginIndexRunIfClear so index/sync refuse while an offload is in flight (offload already blocks on every kind). Tested both directions.
• FinishHookRun terminal guard — mirrored FinishRun's first-terminal-write-wins guard (read status in the finishing tx, refuse with ErrAlreadyFinished when already terminal). Double-finish test asserts the recorded outcome survives.
• --checksum blake3 silent degrade — detect rclone's no hashes in common fallback notice in parseJSONLog at any log level (NOTICE-level events were dropped before), flag it on RunResult, and downgrade rcloneVerification to size+mtime/unverified so the durability vector does not advance on a copy rclone never content-checked. The guard only ever downgrades, so a false match can never wrongly mark a run verified (the chosen err-toward-refusing option for this vector-gating item). Detection keys on the stable substring no hashes in common (the trailing verb has varied across rclone versions).
• config-path ↔ DB-volume-path agreement — added the v.Path != vol.Path cross-check (the same one offload and restore already make) to the shared requireIndexedVolume gate, covering every push handler (bucket, kopia, content-addressed, peer). Mismatch refused before rclone is invoked.
• kopia repo re-create guard — ensureRepository now creates on connect-fail only when --init is set (the same flag that already gates the local-destination marker bootstrap). Without it, a connect failure is a hard error rather than minting a fresh empty repository while the monotonic, un-rewindable durability vector keeps claiming coverage. Test asserts connect-fail without --init refuses and never creates; --init help text and the kopia/integration tests updated accordingly.

Out of scope (note): the issue body's sixth bullet — durability-evidence staleness policy — was not in this PR's task list and is untouched here; it can stay open on #114 or move to its own follow-up.

Verification

• go vet ./... clean
• go test ./... clean (full module)
• golangci-lint run — 0 issues
• TestSchemaSnapshot green after regenerating store/schema.sql

Judgment calls

• v21 is purely additive (trigger DDL + schema_version row), so it uses the plain single-tx recipe (like v18→v20), not the FK-off table rebuild.
• Extended the minimal v18 fixture in destination_run_ids_test.go with the contents table a real v18 DB carries, since the chain now attaches triggers to it.
• Reused the existing ErrAlreadyFinished sentinel for the hook guard (it is the runs-family terminal-write sentinel; callers already errors.Is it).
• For the silent-degrade item, chose output detection over a per-destination hash-capability preflight: detection is self-contained on the JSON log we already parse and is fail-safe (downgrade-only). No follow-up filed — the implemented guard is the conservative one the task asked for.