Add isolated Fly agents with per-agent model selection

[Annedaynl]

What changed

• add a Fly.io managed-agent backend that provisions one isolated app, Machine, volume, and secret set per agent
• add a reviewed, uniquely tagged Fly agent image and deployment examples
• let a linked agent override its own LLM provider and model without changing the reusable persona
• remove the parallel agent-owned MCP profile/editor and document the Project-owned connection boundary
• migrate retired agent-owned MCP values out of Desktop records and staged Fly secrets before deployment

Why

Cloud agents previously depended on inherited persona/global model settings. That prevented owners from independently choosing Claude or GPT for each agent.

MCP endpoints, commands, credentials, health, and discovered tools belong to the Project connection introduced by #4588 and the shared transport work in #4164/#4271. An agent should eventually carry only a connection binding plus an optional tool allowlist. This PR no longer creates a competing MCP document or stores MCP credentials in an agent configuration.

Owner experience

In Edit Agent, an owner can choose an agent-specific Buzz Agent provider, model, and credential before launching the Fly Machine. Existing local/default behavior remains unchanged.

Custom MCP connections are not added by this PR. Fly agents will need a Project-owned HTTP/cloud-reachable connection (or a future gateway); they cannot execute a Desktop-local stdio server. Agent bindings and the hosted HTTP path remain follow-up work.

Validation

• Desktop JavaScript: 4,132 tests passed
• Desktop TypeScript and repository checks passed
• full Desktop Rust workspace passed
• full buzz-acp, buzz-agent, and buzz-backend-fly package suites passed
• warning-denying Clippy passed for Desktop and all changed runtime packages
• published pilot-20260804-project-mcp-boundary as manifest sha256:8e6e63b81741002b19f62583e32fbf3be6e3cfb2bd1b1af46b3c496bc7ed77a3

Originating Buzz channel: AI Management (5038ba1c-66e8-4fb4-a96f-0a5801126938).

[wolfyy970]

I opened #4588 for the Project-owned side of this. It lets a connection be configured and tested once at the Project level, while agents bind to it without carrying or duplicating credentials. I think that boundary complements the per-agent Fly settings here.

[Annedaynl]

Thanks — I agree with this boundary.

• Project owns the connection: transport-specific endpoint/command, credentials, health/test state, and discovered tools.
• Agent owns only a binding: a Project connection ID plus an optional exact tool allowlist. Portable agent/persona/template data must not carry endpoints or credentials.
• One schema: buzz-acp: add structured MCP server configuration #4164 should own the versioned MCP document, with feat(acp): support remote HTTP MCP servers #4271 adding HTTP. Add isolated Fly agents with per-agent model selection #4571 should consume that shared model instead of introducing a parallel BUZZ_ACP_MCP_SERVERS configuration contract.
• Runtime constraint: local agents may bind stdio connections. Fly agents cannot execute a Desktop-local stdio process, so they must bind a cloud-reachable HTTP connection (or a future gateway that makes a Project-owned stdio connection reachable).
• Cloud secret materialization: when a Fly agent starts, Desktop/control-plane code must resolve the Project credential and provision a runtime copy into that Machine's secret boundary. “No duplicated credentials” should mean no credential duplication in portable agent configuration; without a token broker, the runtime still needs a scoped operational copy.
• Model credentials stay per agent: selecting Claude/GPT and its account remains independent from Project-owned MCP connections.

I’ll adapt #4571 around that split: retain isolated Fly/runtime and per-agent model selection, remove the agent-owned connection editor/parallel MCP profile, and make the hosted MCP portion build on the Project binding + shared transport schema rather than owning credentials itself.

[wolfyy970]

Thanks. The runtime-scoped secret copy is the right correction to “no duplicated credentials.” I have the local binding path in #4735: a template declares capabilities, the owner chooses a Project connection, and the agent stores only that binding.

One boundary should stay explicit: neither Buzz nor #4735 currently enforces an exact per-tool allowlist. Binding an MCP server grants its full tool surface. I would leave allowlists out of the UI and stored contract until the runtime can enforce them.

For Fly, the same binding can resolve to a cloud-reachable HTTP connection and scoped runtime secret copy at launch. That gives local and Fly agents the same model without putting endpoints or credentials in portable templates.