Scale changed-path ledger for large repositories

[forhappy]

Summary

• activate the changed-path ledger across observers, recovery, status, diff, record, patch application, API, and MCP paths
• automatically reconcile filesystem state and start or replace per-workspace daemons on status, diff, and record
• avoid repository-wide scans by consuming authenticated changed-path candidates and controlled projection intervals
• add fail-closed workspace activation and clear reinitialization guidance instead of migration or backward-compatibility behavior
• add native Linux/macOS coverage, strict scale thresholds, benchmark tooling, CI/release gates, and production diagnostics

Why

Large repositories such as the Linux kernel can contain 100,000 or more files. Recording and applying lane changes previously risked repeated full-tree traversal, stale daemon ownership, and WAL/checkpoint visibility races. Those costs made small changes scale with repository size instead of changed-path count.

This change makes candidate discovery proportional to actual changes, binds observer data to authenticated durable publication, and performs an automatic full reconciliation when continuity cannot be proven.

Impact

Status, diff, record, and structured patch workflows remain fast for sparse changes in large workspaces. Materialized and transparent COW lanes use the same changed-path authority, while stale or incompatible workspaces are rejected with instructions to reinitialize.

Strict 100,000-file runs passed on native Linux and macOS. On the Linux run, sparse materialized records completed in approximately 0.18-0.57 seconds and patches in approximately 0.21-1.21 seconds. The macOS run passed the same candidate-count and no-full-scan assertions.

Validation

• cargo fmt --all -- --check
• cargo check -p trail --all-targets
• 36 benchmark/checker Python tests
• bash -n scripts/cli-scale-bench.sh
• changed-path producer inventory test
• activation, API, Git, recovery, materialized-lane, observer, and daemon-focused suites during implementation
• strict native Linux and macOS 100,000-file scale runs

Branch ancestry

The local repository already contained an unpublished integration stack. Consequently, this head is 147 commits ahead of GitHub's current main; this PR includes that inherited ancestry as well as commit 9e10f7c. Land the ancestor stack first or rebase/retarget this branch before merging if the PR must contain only the changed-path-ledger delta.

Follow-up

This is intentionally a draft. A later hardening pass can complete the full release matrix and refine the materialized-lane REST/daemon lifecycle edge case before final release promotion.