fix(agent-builder): propagate runtime agent installs to fallback even when boot was chat-disabled

[Weegy]

Problem

After installing an agent plugin at runtime, its specialist sub-agent (query_* domain tool) was not pulled into the fallback Agent — neither on a fresh chat session nor after a restart. Channel/connector installs, by contrast, showed up on a new session. That asymmetry was the reported bug.

Root cause

The onInstalled hook for kind: 'agent' activates the agent in dynamicAgentRuntime, then calls propagatePluginInstall?.(agentId) to wire the new domain tool into the per-Agent orchestrators (including the fallback Agent).

But propagatePluginInstall / propagatePluginUninstall (and reconcileRuntimeDomainTool) were assigned only inside the boot-time if (orchestrator) { … } guard. On a chat-disabled boot — no ANTHROPIC_API_KEY at process start, i.e. the Setup-Wizard / Docker path — orchestrator is falsy at boot, so those closures stayed undefined. The optional-chained call then silently no-op'd:

• The agent activated in dynamicAgentRuntime, but the fallback Agent's agent_plugins enablement row was never written.
• scopeDomainToolsToPlugins gates each domain tool on that row → the tool was withheld from the fallback Agent.
• The missing DB row persists, so it is still gone after a restart.

Channels are unaffected because the channel install hook activates them directly (channelRegistryRef.activate) with no plugin-scoping / DB enablement — which is exactly why connectors appeared on a fresh session but specialist agents never did.

Fix

Define the three closures unconditionally (hoisted out of the if (orchestrator) boot guard). They already resolve configStore / orchestratorRegistry live from the serviceRegistry on every call, so they take effect the moment chat goes live via the Setup Wizard — and the enablement row they write now survives restarts. Forward-ref lets become const, and the now-redundant optional chaining at the call sites is dropped.

Pure code-motion + scope change; no behavioural change on the env-key (chat-enabled-at-boot) path.

Verification

• npm run build ✅ (full workspace, ends by compiling src/index.ts)
• eslint src/index.ts ✅ (0 problems)
• tsc --noEmit ✅ (0 errors)
• test/runtimeToolPropagation.test.ts + test/scopeDomainTools.test.ts ✅ (10/10 pass)

Remaining nuance (out of scope)

Installing an agent before the key is set (while orchestratorRegistry doesn't exist yet) still early-returns, but now self-heals on the next restart because the boot hydration reads enablement from the DB. The normal flow (set key → install agents) is fully fixed.