simplify(config): retire legacy sync controls that have no execution consumer #4434

Priority / deletion target

P2 · misleading configuration surface · low/medium compatibility risk. Remove sync.full_sync_escalation_files.v1 and sync.max_concurrent_syncs.v1 from active settings/runtime configuration rather than retaining knobs that no current sync execution reads.

Evidence

At 1bf9f0819465b2720241b20057510ff01dfa633a, SyncConfig advertises full-sync escalation and a daemon-wide concurrent-sync cap, with defaults 500 and 2. Snapshot materialization requires and copies those settings into the runtime value.

Repository-wide searches for both exact field names returned only their declarations/defaults, configuration materialization, registry/default definitions, domain key exports and a historical registry SQL fixture. No execution read was found. The relevant owners are tracedecay-global-db/src/configuration/registry.rs and tracedecay-domain/src/configuration.rs. In contrast, searching read_cooldown_secs finds real MCP lifecycle consumers; this proposal is not a blanket deletion of sync settings.

Search absence alone is not a compiler reachability proof. Revalidate the field/key census on the implementation head and check generic setting lookups before deletion. Do not claim changing either value has been benchmarked in a running daemon.

Exact implementation

1. Verify these two settings' complete callers using the compiler/reference graph and literal-key search. Identify the actual code-index admission and reconciliation controls that now own concurrency and full capture; retain them unchanged.
2. Delete the two unused runtime fields, defaults, required materialization reads, active registry descriptors and exported setting keys. Remove exclusive documentation/generated controls so settings inspection no longer promises an effect they do not have.
3. Handle persisted overrides and released clients explicitly at the existing configuration boundary. Return a clear retired/unsupported setting result or the repository's supported registry-transition response; do not silently reinterpret them as a different concurrency control.
4. Keep historical configuration evidence readable where the current persistence contract requires it. Do not edit old fixture data to conceal the transition, fabricate successful activation, or reset all user settings.
5. Do not implement new behavior merely to justify keeping the old knobs, and do not add a replacement alias/configuration registry. Preserve real watcher, read-refresh, worktree and code-index budget policies.

Acceptance

Current settings list/schema excludes both controls; writes cannot report a successful active policy for them. Supported historical snapshots are handled explicitly. Indexing, on-demand refresh, concurrency admission and source-generation publication behave as before with the actual owning controls. A caller census in the PR shows no overlooked live use; behavioral tests verify the configuration response and normal indexing journey under Bazel. Completion requires removing the controls end to end, not just deleting two struct members.

Targeted issue search found no equivalent full-sync escalation ticket. Separate from #4419's optional PR-autotrack retirement and #4339 dependency defaults. Static audit only; no Rust suite or daemon experiment ran.