Custom ACP providers report available on hosts that cannot execute them

[Danielalnajjar]

Attempted workflow

Select a globally configured custom ACP provider for a thread or workflow targeting an enrolled host other than the server's primary host.

Actual result

BB builds every custom ACP ProviderInfo with available: true and appends globally configured agents after resolving the target host, without probing whether that host can execute the configured command or working directory. Native pickers and workflow resolution can therefore advertise a provider on a host where its executable or adapter does not exist.

Evidence:

• packages/config/src/bb-app-managed-config.ts:116-144 stores one global command and working directory with no host selector.
• apps/server/src/services/providers/acp-provider-tier.ts:93-117 constructs dynamic ACP providers as available.
• apps/server/src/services/system/execution-options.ts:102-137,234-253 resolves a host but appends the global custom agents without a host execution probe.
• apps/server/test/system/execution-options.test.ts:651-687,946-1006 currently codifies listing the custom provider without a usable target-host proof.

Expected result

Custom ACP availability is evaluated for the requested host or environment. A command or working directory that cannot execute there is unavailable or omitted consistently across provider lists, composers, native pickers, and workflow resolution, and selection fails before thread creation with a host-specific non-secret reason.

Acceptance criteria

• Tests cover two hosts where the same global provider is executable on one and unavailable on the other.
• Known-agent probing and primary-host fallback remain intact.
• Availability behavior is shared by picker and workflow consumers rather than reimplemented in each plugin.

AGENT GENERATED: by GPT-5.6 Sol