feat(index): preserve responsiveness during root indexing

[randomvariable]

Summary

• bound executor queues and carry request deadlines across SubC so readers remain responsive under index load
• schedule standing-root search, semantic, and callgraph work as resumable deficit-round-robin slices instead of whole-root passes
• pause new slices under battery-saving or CPU, memory, and I/O pressure with hysteresis; index.resource_policy = "performance" bypasses resource admission while preserving concurrency and correctness bounds
• demote maintenance workers to background CPU and I/O priority and expose queue, policy, pressure, pause, and slice telemetry
• prioritize channel-0 heartbeats and route-bind completions, move allocator slack scans off the transport thread, and skip unchanged standing-root reconciliation work
• cap Pi synchronous transport at 25 seconds and Rust interactive execution at 24 seconds, promoting unfinished bash waits to background tasks before the host deadline
• document the branch architecture and contributor execution paths

Test Plan

• cargo fmt --all -- --check
• cargo test -p agent-file-tools standing_roots
• cargo test -p agent-file-tools callgraph_store
• cargo test -p agent-file-tools search_index
• cargo test -p agent-file-tools semantic_index
• bun test packages/opencode-plugin/src/__tests__/config.test.ts packages/pi-plugin/src/__tests__/config.test.ts
• executor, SubC bridge, timeout, standing-root storm, and release-calibrated storm contracts
• complete Rust, integration, Pi plugin, and bridge regression suites
• isolated many-root daemon health probes with production standing roots kept disabled
• git diff --check

Contribution

AI-assisted implementation and verification with OpenAI Codex through Oh My Pi. The author reviewed the changes and test evidence.

[aft-alfonso]

Thank you - this lands squarely on planes we actively harden, so it will get a thorough review rather than a fast one. Initial scope notes before the deep pass: (1) main moved tonight in exactly this area - the executor's per-actor admission accounting changed (maintenance no longer consumes interactive capacity) and several of the test files you touch were rewritten to event-based assertion form - so a rebase onto current main is worth doing early; expect conceptual interplay between your queue bounds and the new accounting. (2) This bundles three separable features (queue bounding/backpressure, cross-path request budget carrying, maintenance yield/demotion) - if review friction builds, splitting them in that order would let the first land fastest, but we will review as-is first. (3) Concurrency-core changes here go through adversarial review including storm suites on loaded runners - the release storm gate in your test plan is the right instinct. Full review follows.