fix(orchestrator): tools invisible to discovery — never memoize a partial tool listing

[mgoldsborough]

A healthy bundle's tools could become invisible to nb__search / nb__manage_tools for minutes, even though the bundle reported healthy.

Root cause

The cross-workspace tool-list cache memoized whatever the per-workspace lister returned — including a partial listing produced when a source was skipped mid-enumeration because it wasn't ready yet (cold start, subprocess restart, pending auth). That partial/empty snapshot then stuck — served to discovery — until some unrelated invalidation (the workspace.json FS watch, a membership change) happened to fire. The cached union predated the source's readiness, and nothing re-listed it.

Fix part 1 — never memoize a partial listing (d6b710e)

Make the cache correct by construction: a listing carries a complete flag (false iff a source was skipped), and neither cache layer memoizes an incomplete one.

• WorkspaceToolLister returns { tools, complete }; the production lister sets complete=false whenever it skips a not-ready source.
• getWorkspaceListing memoizes only a complete listing; a partial one is returned to the caller but left uncached, so the next ask re-lists.
• getUnionForIdentity memoizes the per-identity union only when every contributing workspace listing was complete; concurrent first-askers share one in-flight fan-out.

This mirrors the existing identity-tools "don't memoize empty" guard (getIdentityDescriptors). It self-heals on the next discovery call once sources are up, with no dependence on an invalidation event firing.

Fix part 2 — don't lose an invalidation that lands mid-compute (f64fd14)

Part 1 introduced a subtle window of its own, caught in review. Pre-PR, the union promise was registered in identityUnions before awaiting and deleted on invalidation — so an invalidateWorkspace firing mid-compute self-healed (the pending entry was dropped; the next ask recomputed and re-subscribed). Part 1 changed the pattern to "set identityUnions only after resolution, and only if complete" — which reopened a clobber window: an invalidation fires mid-compute → clears the workspace's subscribedIdentities and deletes the not-yet-memoized union (a no-op) → the compute resolves and writes a stale union with a now-broken watcher subscription. That's the exact "stale until an unrelated event" failure this PR exists to kill, one window over.

Part 2 closes it with generation/epoch guards so memoization is refused when an invalidation landed during the compute (the in-flight maps stay — they handle correct complete signaling to concurrent callers; the epoch is orthogonal):

• Per-workspace: WorkspaceWatchEntry.generation, bumped in invalidateWorkspace (which now also clears listingInFlight). getWorkspaceListing captures it before the lister and memoizes only if unchanged.
• Per-identity: an identityEpochs counter, bumped in invalidateWorkspace (per subscribed identity) and invalidateIdentity. getUnionForIdentity captures it before the compute and memoizes only if unchanged — so a superseded union is left uncached and the next ask rebuilds and re-subscribes.

This restores the pre-PR self-heal without reintroducing the concurrent-wrong-complete race the in-flight maps fix.

Tests

• Cold-start partial (d6b710e): a partial listing re-lists until complete, then memoizes — regression guard for the invisible-tools outage.
• Mid-compute invalidation (f64fd14): an invalidateWorkspace fired while a union compute is in flight → the next ask re-lists (no stale memo) and the identity is still invalidated by a subsequent change (proving re-subscription). Verified red without the epoch guard.

Existing aggregator + watch + registry-invalidation suites updated for the new lister shape and pass unchanged in behavior. Full verify green locally: static checks, 3300 unit + 666 integration tests, 0 failures.

---

Scope note: the loop-brake (stopping an agent that re-searches for a tool that genuinely isn't there) was split out of this PR. It's defense-in-depth that this fix's trigger no longer needs urgently, and it's being built properly on MCP _meta rather than a structuredContent marker. Tracked separately.