Keep admitted work running when stop-if-idle finds the namespace busy; bump to 1.2.6 - #219

Fixes #218.

Problem

In v1.2.5, stop-if-idle closed catalog admission before it counted protected work. It then always tried to lock activity.lock exclusively, even when the count had already found work. Admission stayed closed until the decision committed, and a lock the probe obtained stayed held until the probe returned, even when the decision was busy. Work accepted before the probe could therefore fail its next admission check with retryable busy/namespace-admission-closed, even though the probe then refused the stop. Two checks fail that way:

• work::ensure_admission rejects while catalog admission is closed. Operation acceptance and owner preparation, registration and claims call it. So do steps inside accepted jobs, including reservations, object creation and pinning, generation opening, metadata mutations, and view attach, reconciliation and publish.
• ActivityGuard::acquire takes activity.lock shared for reservations, owner preparation, catalog handles, object and root guards, collection, inventory and housekeeping. While the probe holds the lock exclusively, the shared lock fails and is reported with the same code.

In #218 this left an accepted views.attach operation failed.

Fix (tgrep-core/src/managed/maintenance.rs)

• The probe first samples receipt readers and external work (requests, queries, queued jobs, background batches). A single catalog transaction then counts unreleased leases and owners, reservations and unfinished operations, and closes admission only when all of them are idle. The count uses the same accepted/preparing/cancelling filter as v1.2.5.
• Operation acceptance, owner preparation and owner registration each call ensure_admission inside the IMMEDIATE catalog transaction that records them, so they serialize with the probe's count-and-close transaction. Every unfinished operation accepted before the closure is counted and makes the probe refuse. A later one gets the documented retryable busy/namespace-admission-closed before acceptance. An accepted operation is never then failed by an idle-probe closure. Owner claims also check admission but write nothing to the catalog. A claim needs an issued, unreleased owner, which the count includes, so an idle probe never closes admission under a claim.
• Visible work (new busy fast path). The probe neither closes admission nor tests activity.lock, and never reaches the IdleAdmissionClosed fault point. Like the v1.2.5 busy decision, it discards only expired verifier caches (discard_idle_verification(true)). It then records its non-stopping result through the same token and operation-result path. It still writes admission='open' as v1.2.5's busy decision did, which also repairs a closure left behind by a failed reopen.
• Nothing visible. The v1.2.5 sequence runs unchanged. With admission closed, the probe rechecks those counts and receipt readers and tests independent namespace/root/object guards through activity.lock. It commits a stop only when every category is idle. A busy result reopens admission and a committed stop leaves it closed. Only a committed stop ends in-flight work.
• Both paths finish through commit_idle_decision, which writes the stopping service record or admission='open' together with the receipt, then hits IdleCommitted.
• No new deadlines, retries or fault points.

Compatibility

• No RPC, field or reason-code changes. stop-if-idle, busy, namespace-admission-* and daemon-admission-closed are unchanged, and stopping keeps its meaning. No CLI change.
• Semantic change to a diagnostic field. IdleOutcome::namespace_readers_or_work is now observed only after admission closes, and is false when the probe refuses before closing it. In v1.2.5 every probe tested activity.lock, so a busy probe could report true. The Copilot runtime reads only stopping, and SHARED_WORKTREE_INDEXES.md did not define this field. The field's doc comment and the stop-if-idle API row now state this.
• The existing managed::collection::tests::busy_idle_probes_preserve_staging_reclamation_and_storage_admission asserted namespace_readers_or_work for a probe that an issued owner and an accepted attachment had already made busy. It now asserts operations == 1 and !namespace_readers_or_work. The inverted assertion fails on v1.2.5 with IdleOutcome { stopping: false, .., owners: 1, reservations: 0, operations: 1, .., namespace_readers_or_work: true, .. }, so it doubles as regression evidence that a busy probe leaves activity.lock alone.

Why there is no deferral, CLI change or race test

• There is no residual window to defer. When a probe sees no work, the transaction that counts operations is the one that closes admission, so it counts every unfinished operation accepted before the closure. The ViewManager::execute deferral list is unchanged.
• The CLI handler holds the process admission mutex for the whole stop-if-idle call. The accept loop and the maintenance tick lock the same mutex, so they wait for the decision rather than being rejected. They see daemon-admission-closed only after a committed stop or an unresolved idle-state-unavailable. Jobs never consult that gate. This corrects step 1 of the issue's code path, which says new connections and receipt polls are rejected mid-probe.
• A race test would pass on v1.2.5 too: an attach either completes while the daemon stays, or is rejected before acceptance while it stops. Acceptance during a genuine closure was already rejected before acceptance in v1.2.5, and atomic_idle_admission_rejects_new_owners_operations_and_independent_readers covers that.

Tests

The new tests use existing managed-test-hooks fault points (IdleAdmissionClosed, IdleCommitted). They synchronize on hook state or probe completion, without sleeps, retries or longer timeouts. With only tgrep-core/src/managed/maintenance.rs reverted to v1.2.5 (tests unchanged), each one fails:

Adjusted existing daemon test. managed::clients::escaped_cross_process_readers_block_collection_and_idle_stop_then_allow_exact_rebuild expects an escaped cross-process reader to show up as namespace_readers_or_work: true. Its idle_status helper took the first non-busy probe outcome. With this change, a probe that happens to see other daemon work refuses before it closes admission and reports false. Two sources of such work already exist in v1.2.5:

• the scheduler pass counted in background_batches;
• the preceding RPC, whose request guard drops only after its response is written.

With the fix and v1.2.5's helper, the test failed this way (left: Bool(false)) in 11 of 20 runs. The helper now repeats the probe until an outcome shows no other work: every lease, owner, reservation, operation, receipt-reader and external count is zero. It polls every 20 ms, like the existing stop() helper, within a 10 s bound. Only a probe that closed admission and tested activity.lock can return an outcome like that. The assertions are unchanged, apart from now printing the outcome. No product code depends on this.

Reproduction and stress runs

At this PR's head, each run a separate cargo test --locked ... --features managed-test-hooks ... --exact invocation. The v1.2.5 rows check out only tgrep-core/src/managed/maintenance.rs from refs/tags/v1.2.5, then restore it.

The adjusted helper passes against both v1.2.5 and fixed product code, and still asserts namespace_readers_or_work: true for the escaped reader.

Release

• Bumps the version to 1.2.6, the same way as 7951103: Cargo.toml, Cargo.lock, fuzz/Cargo.lock and the two CONTRIBUTING.md examples.
• SHARED_WORKTREE_INDEXES.md updates the typed claim failures, the stop-if-idle API row, and the idle-stop sequence and recovery text. The activity.lock layout entry keeps its v1.2.5 wording, which is still accurate: work and independent readers hold that lock shared, and only a probe that has closed admission tests it exclusively.
• Not part of this PR: merging, tagging, running release.yml or sign-and-release.yml, or publishing a release.

Validation

Run one at a time at this PR's head, f606863, on Windows 11 Enterprise (16 logical CPUs) with rustc/cargo 1.98.0, rustc 1.88.0 and Python 3.14.7. git status --porcelain was empty before and after. TGREP_V1_BINARY and TGREP_V1_READER, which only the shared_daemon managed tests read, pointed to the debug tgrep and legacy_reader example built as ci.yml builds them: a git archive of the pinned 1120aca, prepared with scripts/qualification/prepare_legacy.py. The Rust 1.88 rows used the windows-msrv job's environment (CARGO_BUILD_JOBS, RAYON_NUM_THREADS and RUST_TEST_THREADS set to 2, plus its hardening RUSTFLAGS) with CARGO_TARGET_DIR=target\msrv.

Pre-existing failure, out of scope. Without managed-test-hooks, managed::polling_modes_repair_unreported_restored_mtime_and_membership_changes fails at tgrep-cli/tests/shared_daemon.rs:151 with unknown managed method: testing.reconcile-timer. That RPC exists only with the feature, but the test is not gated on it. Unmodified v1.2.5 fails the same way: from a git archive of v1.2.5, cargo test --locked -p tgrep-cli --test shared_daemon -- managed::polling_modes_repair_unreported_restored_mtime_and_membership_changes --exact exits 101 with the identical panic. CI always enables the feature, and the test passes in the feature runs above. This PR leaves it unchanged.

Not run locally: the Linux and macOS jobs, including the Unix installer test and the scripts/agent integration tests, which CI runs only off Windows.