Enforce execution-mode eligibility across provider selection and fallback

[atomantic]

Decision: docs/plans/2026-09-06-provider-connections-and-harnesses.md (planning issue #6359). Retain executable provider IDs for all saved selections; durable connection IDs are management-only. This is implementation work, separate from the planning deliverable.

Centralize caller allowed modes and required model capabilities at the server selection boundary using existing executable provider records. Apply the policy to explicit pins, activeProvider inheritance and every fallback candidate. This slice can ship before durable graph persistence.

Areas: server/lib/aiToolkit/providerStatus.js, server/services/agentModelSelection.js, server/lib/orchestrationProfile.js, client/src/components/ProviderModelSelector.jsx, client/src/utils/providers.js, caller policy wiring.

Acceptance:

• CLI/API-only contexts never select TUI via inheritance, task pins or fallback.
• Separate CLI/TUI route IDs remain in selectors; disabled/stale/ineligible saved values remain visible with a reason and are not silently replaced.
• Preserve task/app/profile role precedence and existing fallback references; unknown required capabilities do not become true.
• Missing harness/runtime or TUI-specific failure does not disable healthy direct API execution on the same backend.
• Public workflow tests cover schedule/CoS/profile + fallback, and rendered selection behavior; avoid redundant helper assertion matrices.
• No connection graph, storage migration or peer wire change is needed. Preserve existing readiness policy where requirements are unknown.

Part of #6359
The parent is a completed planning deliverable, not an implementation epic; do not reopen it.