Project Settings allows switching to unsupported orchestrator agents without preflight install/auth checks

[nikhilachale]

Summary

The orchestrator agent picker currently lets users switch to agents even when AO does not know whether that agent is installed or authenticated. That creates a
broken switch flow:

• if the agent is not installed, it should not be selectable as a runnable orchestrator target
• if the agent is installed but not authenticated, should not be selectable as a runnable orchestrator target
• if switching triggers the agent’s own login/bootstrap flow, that can spawn a fresh session outside AO’s normal orchestrator startup path, so the replacement
  session may miss AO’s system prompt / expected initialization

This means the settings UI can present options that are not actually safe to switch to.

Problem

Today the user can pick an orchestrator agent without a reliable preflight check for:

• supported by AO
• installed locally
• authenticated / ready to run

That leads to two bad outcomes:

• The agent still appears in the switcher.
• The user can save and attempt a restart.
• Restart then fails late instead of the UI blocking the choice up front.
• The switch is allowed.
• The agent may prompt for login during startup.
• That login flow can create a new session/process that AO did not initialize the normal way.
• The resulting session may not receive AO’s system prompt and expected orchestrator bootstrap.

Expected behavior

• The switcher should only present agents in states the user can act on clearly.
• Unsupported or unavailable agents should not look like normal selectable options.
• If an agent is not installed, the UI should show that state and block switching.
• If an agent is not authenticated, the UI should show that state before save/restart, not only after failure.
• AO should only cut over to a new orchestrator when the target agent is actually ready to launch through AO’s normal startup path.

Why this matters

This is not just a UX issue. It can produce orchestrator sessions that start outside AO’s intended initialization path, which risks missing the system prompt
and breaking orchestrator behavior in subtle ways.

Acceptance criteria

• Agent catalog API exposes per-agent readiness state: supported, installed, authenticated.
• Project Settings uses that catalog instead of treating every known agent as equally selectable.
• Uninstalled agents are not shown as normal switch targets, or are visibly disabled with an install-required reason.
• Installed but unauthenticated agents are clearly marked before switching.
• Save/restart is blocked unless the selected orchestrator agent is runnable through AO.
• Switching cannot fall into an external login/bootstrap path that bypasses AO’s normal orchestrator initialization.
• Tests cover:
  • uninstalled agent
  • installed but unauthenticated agent
  • installed and authenticated agent
  • restart path preserving AO system-prompt initialization