Bundle goose as default agent harness

Start by tracing buzz-acp's agent packaging and runtime entry points, then inspect managed_agents.json, buzz-persona, the buzz-agent-snapshot v1 import path, OAuth reset paths, and K8s/shared-compute descriptors. Resolve the build-versus-binary and migration questions before changing implementation. Done means goose is the default bundled agent, existing configurations and deployments have a defined migration or compatibility path, and supported release builds work.

Goal: Package goose in Buzz as the default agent, replacing buzz-agent

Objective: Replace the built-in buzz-agent with goose (https://github.com/aaif-goose/goose/) as Buzz's default bundled ACP agent. Buzz's harness (buzz-acp) is already agent-agnostic - goose is a supported runtime today - so this is primarily a packaging change plus closing a small set of product-feature gaps.

Buzz can use a "lean" build of goose, cutting many optional features in favor of a lightweight ACP-only harness.

Open questions:

Build from source or download release binary?

• Build goose from source (vendored rev or git dependency) in CI. Reproducible and signable as our own artifact, but adds a goose build to every release pipeline. Pros: buzz can opt in/out of build-time features, control supported platforms
• Download binary: this would require goose to publish "lean" binaries for all supported platforms. Buzz would pin to a version

Migrating existing user agent configs

• Managed-agent records (managed_agents.json per community): existing agents with agent_command: "buzz-agent" — do we auto-rewrite them to goose, mark them broken with a guided migration UI, or keep recognizing
  the id as an alias that maps to bundled goose? Auto-rewrite must also translate env: BUZZ_AGENT_MODEL/PROVIDER/THINKING_EFFORT/MAX_* → GOOSE_MODEL/PROVIDER/THINKING_EFFORT/MAX_TOKENS/CONTEXT_LIMIT, and there's
  no goose equivalent of BUZZ_AGENT_MAX_ROUNDS.
• Personas (buzz-persona): runtime: buzz-agent personas emit BUZZ_AGENT_* env vars; snapshots/exports (buzz-agent-snapshot v1 format — note the format name survives, it's agent-definition export, not the agent)
  may embed the runtime id and be re-imported on other machines. Import path needs a mapping or rejection policy.
• Provider/model settings: users configured on Databricks via buzz-agent's picker — does their model selection carry into goose's Databricks provider (different model-id namespace? databricks_v2 vs goose's
  provider naming)? Internal builds baked BUZZ_BUILD_BUZZ_AGENT_PROVIDER/MODEL defaults — what's the goose-equivalent baked default?
• OAuth token caches in ~/.config/buzz-agent/ — migrate, ignore, or clean up? (Reset paths already delete them.)
• K8s/shared-compute descriptors: deployed agents with BUZZ_ACP_AGENT_COMMAND=buzz-agent in cluster state; image contents must include goose, and old pods need a redeploy story.

Rollout

To mitigate the complexity of the above items, should there be a period where goose is packaged and default, but buzz-agent continues to exist and support existing configured runtimes?