Goose harness "Custom provider" (raw base-URL) integration is broken

## Setup

Agent defaults → Default harness: **Goose** → Provider: typed a custom OpenAI-compatible base URL (e.g. `https://your-endpoint/v1`) instead of picking a built-in provider → Model: "Custom model..." with a model id typed in.

## What happens

Every agent using this config fails on every message. `goose acp` logs show:

```
Sending error response ... method: "session/new"
error: Error { code: -32603: Internal error, message: "Internal error",
data: Some(String("Failed to resolve model: Configuration value not found: GOOSE_MODEL")) }
```

## Root cause

Confirmed via `ps eww ` on the live `goose acp` subprocess — the actual environment it receives:

```
GOOSE_MODEL= <- correct
GOOSE_PROVIDER=https://your-endpoint/v1 <- WRONG. This is the raw base URL, not a provider id.
OPENAI_API_KE=sk-... <- WRONG NAME (see Bug 2)
```

goose's provider registry only accepts known ids in `GOOSE_PROVIDER` (`openai`, `anthropic`, `openrouter`, etc.), never a URL. The base URL belongs in `OPENAI_HOST`, but Buzz never sets that var at all — it puts the URL straight into `GOOSE_PROVIDER`, which goose can't resolve, so provider resolution fails before it ever reaches the model or key. The `-32603` / `GOOSE_MODEL not found` error is misleading — `GOOSE_MODEL` is actually set correctly; the real failure is upstream, in provider resolution.

## Bug 2 (separate, compounding)

Manually adding an env var named `OPENAI_API_KEY` in the Agent defaults "Environment variables" UI gets silently truncated on save to `OPENAI_API_KE` (missing the trailing Y) — confirmed by reading the actual process env as above. So even a manual workaround for Bug 1 can't supply a correctly-named key.

## Also

Trying to manually add env var rows named `GOOSE_PROVIDER` or `GOOSE_MODEL` to override Buzz's own (broken) auto-injected values gets rejected on save ("Couldn't save.", no further detail) — presumably a reserved-name collision, but there's no UI path to correct the auto-injected `GOOSE_PROVIDER` value.

## Net effect

Any Goose-harness agent pointed at a custom/self-hosted OpenAI-compatible endpoint is unusable, regardless of what's entered in the config screen. The built-in "OpenAI-compatible" provider option has no base-URL field either, so it can't be used as a workaround (it only points at literal `api.openai.com`).

## Environment

- Buzz version: v0.4.24
- Workaround used: switched affected agents from "Goose" harness to "Codex" harness with OpenAI auth instead.