#1338 Views: call-graph reads answer within seconds instead of waiting for a full rebuild

With views on, a call-graph read (aft_callgraph, aft_zoom with call-graph details, aft_inspect dead code) could block for a whole re-materialization of the checkout's call-graph view after files changed. One zoom waited 77 s, past the client's 60 s deadline.

• A checkout's call-graph acquisition is now root-owned, cancellable, and runs as a single executor job per view. A read waits at most about 3 s, then answers with the existing "building" state. The next read uses the new graph once acquisition completes.
• A publication fence stops an acquisition that finishes after its root was quiesced from publishing into the released root.
• Native call-graph reads no longer wait on build permits.
• Cancellation reaches every unfinished acquisition, including a completion tail that overlaps a new acquisition. A submitting worker never drops the executor's last owner on itself, so a teardown can't join a worker that's waiting on it.
• Only call-graph acquisition takes the special maintenance slot. Other heavy maintenance work keeps its existing concurrency.

Tests: the unbounded re-materialization and the late publication after quiesce were reproduced first, and so were the three review findings: last-owner drop during submit, maintenance overlap, and cancellation of an overlapping tail. On changed-checkout fixtures, reads answered in 3.0 s and the next reads completed in 18–22 ms, for both standalone and daemon callers and zoom.

Gate: 1,372 executor, views, configure and context library tests, 140 call-graph, views and daemon-search integration tests, -D warnings, formatting and the Windows check. No agent-visible text, schema or tool-argument changes.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

With views on, a call-graph read no longer waits for the whole call graph to rebuild after files change. It returns the existing "building" state within about 3 seconds; the next read uses the new graph once acquisition completes. One zoom previously waited 77 s, past the client's 60 s deadline.

• Acquisition is root-owned, cancellable, and runs off the request thread as one executor maintenance job; a timed-out read keeps the worker running rather than restarting it.
• A publication fence blocks a late-finishing acquisition from publishing into a quiesced root.
• Cancellation reaches all unfinished acquisitions, including completion tails overlapping a new acquisition, and a submitting worker never drops the executor's last owner on itself.
• Only call-graph acquisition takes the special maintenance slot; other heavy maintenance keeps its existing concurrency.
• Typed busy/building view errors are classified as planned and skip failure accounting; real errors still count.
• Test fixtures await acquisition via a shared completion-driven waiter with a 120-second deadline; production reads keep the three-second budget, and the worker preserves the caller's test-only attribute policy.
• Tests cover the unbounded re-materialization, late publication after quiesce, and the three review findings (last-owner drop, maintenance overlap, overlapping-tail cancellation). On changed-checkout fixtures, reads answered in 3.0 s and subsequent reads in 18–22 ms. No agent-visible text, schema, or tool-argument changes.