fix: stop the data.reference seed from wiping CoS settings on the #6182 update

[atomantic]

Summary

CoS stopping after update.sh, and its settings reverting to shipped defaults, are one bug. update.sh runs scripts/setup-data.js — which copies every data.reference/ file the install is missing — before scripts/run-migrations.js. The commit that added migration 339 (lift the durable CoS config out of data/cos/state.json into data/cos/config.json) also added a data.reference/cos/config.json seed. So on the one update that crossed that commit:

1. setup-data wrote the seed into data/cos/config.json
2. migration 339 saw its output "already exists" and no-opped
3. loadConfig() preferred the seed file, so its legacy state.json read never fired
4. the next saveState() stripped the real config slice off disk permanently

The seed carried alwaysOn: false where DEFAULT_CONFIG carried true, which is why CoS also stopped auto-starting after each update. Installs that updated before or after that commit never see it — which matches a second machine on the same version being unaffected.

Changes

• Delete data.reference/cos/config.json. It is a derived file, not a seed — loadConfig() already returns DEFAULT_CONFIG when it is absent, so the defaults now have one source instead of two that had drifted.
• scripts/lib/migrationOwnedPaths.js — declares paths a migration derives from existing records; honored by both setup-data copy paths, with a test that fails if such a seed reappears.
• Migration 340 — where config.json is still the shipped seed, redo 339's lift from state.json, or from the newest quarantined state.json.corrupted.* when the live slice is already gone, or delete it so the in-code defaults apply. A config.json carrying real settings is never touched — but if a quarantined backup holds settings it lacks, the migration names that file so a user who re-entered settings by hand can recover the rest.
• DEFAULT_CONFIG.alwaysOn now defaults to false. It read true only because the seed masked it; with the seed gone, a fresh install would start CoS and its autonomous jobs unprompted, which "No cold-bootstrap LLM calls" forbids. Every existing install has a stored value and is unaffected.
• AGENTS.md — records the rule: a migration that derives data/<x> from existing records ships no seed, and gates on the presence of its input rather than the absence of its output.

Rejected alternative

Reordering update.sh to run migrations first: run-migrations creates data/, which would send fresh installs down setup-data's existing-install branch and skip the __PORTOS_ROOT__ substitution. setup.sh / setup.ps1 / npm run setup also do not run migrations at all.

Test plan

• Migration 340 covers all six branches: lift from a live slice, recover from the newest quarantined backup (skipping one without a slice), delete when nothing is recoverable, leave a user-written config alone, no-op when absent, and no-op when unreadable.
• RETIRED_SEED is asserted against the seed extracted verbatim from the commit that shipped it (scripts/migrations/__fixtures__/) — without that witness the equality guard compares the constant to itself and would pass for any value it held.
• The seed-absence guard and the alwaysOn default pin were both bypass-probed (re-adding the seed / flipping the default each fails the suite).
• Full server suite green (39k+ tests); CoS client suites green.