fix(global-db): keep session schema bumps off global.db

[ScriptedAlchemy]

Root cause

Every registered store (global.db, user-sessions.db, projects/<id>/sessions.db) installs the one unified registered schema, so global.db also records the LCM, git-correlation and workflow schema markers. Admission (classify_registered_schema_authorities) refused any store whose marker differed, and the reset census maps a refused StoreShardScopeV1::Profile to profile authority. So the LCM 13 → 14 bump (#2864) listed global.db as reset-required, wipe --stale would delete the project registry, usage accounting and remote-deletion records, and project commands refused until every project was init-ed again.

The code shows option (a) holds: global.db holds no LCM data any production path reads or writes. LCM compress/boundary writes refuse non-session stores (NotASessionStore), observations (the only source of lcm_raw_messages rows) route only to ProfileSessions/ProjectSessions, retention/payload GC run over mounted_session_databases() only, the privacy rescan uses the project session DB, Work/workflows register on the project session DB, and every lcm_ingest_raw_message caller is a test.

Change

• schema_stages.rs: a store's scope now decides whether it hosts the session features. An existing profile authority no longer admits, refuses, re-ensures or converges the LCM, git-correlation or workflow schemas (SessionFeatureSchema::NotHosted). Its LCM marker is never read, and its old tables and markers stay inert. A fresh profile authority still gets the whole registered schema, because the authority triggers reference lcm_raw_messages. Session stores keep their scoped refusal and reset.
• Audit of the other stages perf(store-runtime): census only unadmitted session stores #2957 lists in the digest: session-temporal already drops and reinstalls an empty earlier version (EmptyEarlier, the case global.db is in), and observation markers refuse only when observation rows exist. So neither resets the registry. git correlation and workflow identity refused on any mismatch, which had the same coupling, so they get the same treatment as LCM.
• docs/USER-GUIDE.md: states that a session-feature schema change never resets the registry.

Proof

Fail before / pass after, with the fix reverted (hosts_session_features → true):

• tracedecay-global-db schema_stages::tests::released_session_feature_markers_refuse_session_stores_but_not_the_profile_authority: FAILED (global.db refused ("LCM", Some(13), 14)), passes with the fix.
• transport_acceptance_suite stale_project_sessions_census::lcm_13_profile_resets_its_session_stores_and_keeps_the_registry (the v1.0.0-beta.65 shape: every store at LCM 13): FAILED, doctor listed Store profile authority requires reset (LCM profile schema 13 ...). Passes with the fix: one census names profile sessions plus both project sessions stores, both projects stay registered through the reset without init, and global.db stays byte-identical.
• stale_sessions_store_reset::session_stores_at_shipped_lcm_schema_13_refuse_sessions_only_until_their_scoped_reset (now also ages global.db): FAILED (census never matched), passes with the fix. The git-correlation and workflow cases also age global.db and pass, and every case now asserts tracedecay_project_list still returns the project.

Runtime journey: debug tracedecay built from this branch, isolated HOME, daemon under systemd-run --user --scope -p MemoryMax=6G. After init, every store's LCM marker was set to 13 (global.db, user-sessions.db, projects/proj_84c124fad27b5e12/sessions.db):

$ tracedecay status --json | jq .reset_required_stores
[ {"authority":"LCM","found_version":13,...,"required_version":14,"store":"profile sessions"},
  {"authority":"LCM","found_version":13,...,"required_version":14,"store":"project sessions proj_84c124fad27b5e12"} ]
$ tracedecay tool tracedecay_project_list   -> ['proj_84c124fad27b5e12']
$ tracedecay doctor
  … Store profile sessions requires reset (LCM profile schema 13 ...). Pending operator action: run `tracedecay wipe --stale --yes`
  … Store project sessions proj_84c124fad27b5e12 requires reset (...)
2 pending operator action(s), 6 warning(s), no issues.   (exit 75)
$ tracedecay wipe --stale --yes
reset profile sessions (4 entries removed ...); the daemon recreates it empty
reset project sessions proj_84c124fad27b5e12 (5 entries removed ...); the daemon recreates it empty
# restart
$ tracedecay status --json | jq .reset_required_stores   -> []
$ tracedecay tool tracedecay_project_list                 -> ['proj_84c124fad27b5e12']   (no re-init)
$ tracedecay doctor -> 5 warning(s), no issues. (exit 0)
global.db: lcm marker 13 (inert), code_projects = [proj_84c124fad27b5e12], lcm_raw_messages rows 0

Suites (all non-zero counts): tracedecay-global-db --lib 390 passed; transport_acceptance_suite typed_terminal_restart_acceptance 17 of 18 pass after rebase. The 18th, reset_required_serving::copying_session_temporal_store_is_served_typed_until_its_named_reset, fails on master because #2975 bumped session temporal to 8 and the test still expects 7; filed as #2991. Also mcp_suite 617 passed; tracedecay-application lib 486, application_suite 66, pr_tracking 7; tracedecay-store-runtime lib 134; tracedecay-dashboard-api lib 177; tracedecay-daemon-service lib 325. cargo clippy -p tracedecay-global-db -p tracedecay --all-targets --features tracedecay/test-transport,tracedecay/test-helpers -- -D warnings is clean, cargo fmt --all -- --check is clean, and the Windows cargo check --workspace --all-targets --target x86_64-pc-windows-gnu --features tracedecay/test-transport,tracedecay/test-helpers,tracedecay-cli/test-transport exits 0.

Fixes #2979

---

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8ff3e12

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.