Goose harness: Buzz injects GOOSE_PROVIDER=openai-compat (invalid), overriding a working Goose config; surfaces as a Codex error

## Summary

When the harness is **Goose** and the provider is **OpenAI-compatible**, Buzz passes its own internal provider identifier straight through as `GOOSE_PROVIDER`:

```
GOOSE_PROVIDER=openai-compat
```

Goose has no such provider. Its engine identifiers are `openai`, `openai_compatible`, `anthropic`, `anthropic_compatible`, `ollama`, `ollama_compatible` — underscored and unabbreviated. Critically, the env var also **overrides** whatever is configured in `~/.config/goose/config.yaml`, so a working Goose install stops working the moment Buzz drives it.

## Symptom

Every turn fails with a message about a completely different tool:

> Turn error · error: The agent's harness reported an internal error. For Codex agents this can mean the configured model isn't supported by your installed `codex-acp` — check the model in `~/.codex/config.toml` or upgrade the adapter (`brew upgrade codex-acp`).

`codex-acp` was not installed on this machine and the harness was Goose. In the agent log it appears only as:

```
WARN buzz_acp: agent_returned (application error — pipe intact) agent=0 outcome="error"
configured_model=glm-5.2 error=Agent reported error (code -32603): Internal error
```

## Reproduce

```bash
GOOSE_PROVIDER=openai-compat GOOSE_MODEL= goose run -t "say hi"
# error: Error Unknown provider: openai-compat.

GOOSE_PROVIDER=zai GOOSE_MODEL= goose run -t "say hi"
# Hi there! 👋 How can I help you today?
```

Goose itself works standalone with its own config; it fails only under Buzz, because of the injected variable.

## Diagnosis

Not visible from the UI or logs. I had to replace the Goose binary with a shim that tee'd the spawned process's environment, which showed `GOOSE_PROVIDER=openai-compat` being injected.

Note `BUZZ_ACP_AGENT_COMMAND` is forwarded to the child but not acted on — Buzz manages its own Goose binary — so it cannot be used to interpose a wrapper.

## Suggested fix

Translate Buzz's internal provider id to the target harness's vocabulary before injecting it, or omit `GOOSE_PROVIDER` entirely and let Goose use its own configured `active_provider`. The current behaviour silently overrides a valid local configuration with an invalid value.

## Impact

Anyone selecting **OpenAI-compatible** with the **Goose** harness — i.e. any third-party or self-hosted model endpoint. The error text actively misdirects toward Codex.

## Environment

- Buzz Desktop 0.5.x, macOS arm64
- Goose 1.45.0
- Relay: self-hosted, built from source

## Related

Same family as #3636, #4278 and #3824 — internally-known information that never reaches the operator.

Start at the Goose harness entry point that injects GOOSE_PROVIDER and trace how Buzz's openai-compat identifier reaches the child process. Reproduce with the documented Goose commands, then verify that the provider is translated to Goose's openai_compatible name or omitted so its configured active_provider remains effective, with a regression test for the injected environment.

Written by the indexing model from the issue text.