Saving a custom provider does not set Goose's default provider/model, leaving Goose unavailable

### Before filing

- [x] I searched [open and closed issues](https://github.com/block/berd/issues?q=is%3Aissue) for duplicates.
- [x] I reproduced this on the [latest release](https://github.com/block/berd/releases).
- [x] This is one bug, not several bundled together.

### Closest existing issue

none found

### What's broken

Saving a valid custom OpenAI-compatible provider writes the provider JSON and stores its credential, but it does not persist Goose's active provider and model. Goose remains `not_ready` and cannot be selected in a chat, even after restarting Berd. In this case it was Opencode Zen.

### Steps to reproduce

1. Start with a Goose profile that has no saved default provider or model, then launch Berd.
2. Open Settings and use the provider connection dialog to create a custom OpenAI-compatible provider.
3. Configure the provider with:
- Name: `OpenCode Zen`
- API URL: `https://opencode.ai`
- Base path: `/zen/v1/responses`
- Authentication: enabled, with a valid OpenCode Zen API key
- Model list including `gpt-5.6-luna`
4. Save the provider. The resulting custom-provider file is valid and contains the expected base URL, base path, and model list.
5. Return to either a new chat or an existing chat with prior history and open the agent/model picker.
6. Observe that Goose is unavailable and reports `not_ready`.
7. Quit and relaunch Berd.
8. Observe that Goose is still unavailable.

### What you expected to happen

After Berd successfully saves and verifies the custom provider, it should save that provider and one of its models as Goose's active defaults when Goose has no defaults yet. Goose should become selectable without editing Goose configuration files manually.

### What actually happened

Berd created this provider configuration successfully:

```json
{
"name": "custom_opencode_zen",
"engine": "openai",
"base_url": "https://opencode.ai",
"base_path": "/zen/v1/responses",
"requires_auth": true
}
```

However, `~/.config/goose/config.yaml` still had no `GOOSE_PROVIDER` or `GOOSE_MODEL` entry. The bundled Goose diagnostic reported that no provider was configured, so Berd continued to classify the Goose harness as `not_ready`. Restarting Berd did not change that state.

The workaround was to add these entries manually:

```yaml
GOOSE_PROVIDER: custom_opencode_zen
GOOSE_MODEL: gpt-5.6-luna
```

After reloading Berd's Goose process, the same provider passed its authentication and connection checks and Goose became selectable.

### How often does it happen?

Every time — reliably reproducible

### Berd version

0.6.2, the latest release at the time of reporting

### Operating system

macOS (Apple Silicon)

### Model and provider

Opencode Zen, all models

### Relevant log output

```text
The app log repeatedly classified the harness as not ready before the workaround:

[2026-08-20][01:17:41][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=harness_not_ready duration_ms=580
[2026-08-20][01:26:06][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=harness_not_ready duration_ms=1
[2026-08-20][01:27:17][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=harness_not_ready duration_ms=1

Before the workaround, the bundled Goose diagnostic returned:

Provider Check:
Provider: not configured: Configuration value not found: GOOSE_PROVIDER

After adding the two missing default entries and reloading Goose, the diagnostic returned:

Provider Check:
Provider: custom_opencode_zen
Model: gpt-5.6-luna
Auth: ok
Connection: ok
```

### Screenshots, recordings, or other context

I did not patch the Berd application or its bundled Goose binary. The only persistent manual change was adding `GOOSE_PROVIDER` and `GOOSE_MODEL` to `~/.config/goose/config.yaml`; I then reloaded the Goose process.

A read-only inspection of current `main` suggests that custom-provider creation and update refresh the provider catalog and model cache, but do not call the existing default-selection helper:

- [`useCustomProviders.ts`](https://github.com/block/berd/blob/main/src/features/providers/hooks/useCustomProviders.ts) saves the custom provider and refreshes its models.
- [`useCredentials.ts`](https://github.com/block/berd/blob/main/src/features/providers/hooks/useCredentials.ts) calls `saveDefaultProviderSelection(providerId)` for configured built-in providers when readiness is `needs_setup`.
- [`defaultProviderConfig.ts`](https://github.com/block/berd/blob/main/src/features/providers/defaultProviderConfig.ts) already persists both defaults and refreshes the readiness store.

The likely fix is to give successful custom-provider setup the same conditional default-selection behavior, without replacing an existing default provider.

This report is only about the missing Goose defaults and readiness state. Endpoint path composition is a separate concern and is not included here.

Bug identified and fixed by GPT 5.6 Sol from a Berd chat, this report was generated by 5.6 Sol in Berd as well.

Start with src/features/providers/hooks/useCustomProviders.ts and compare its successful setup flow with useCredentials.ts, which calls saveDefaultProviderSelection. Read src/features/providers/defaultProviderConfig.ts to understand how defaults and readiness are refreshed. Done means a newly saved custom provider selects a model only when no defaults exist, persists both Goose defaults, and becomes selectable after reload without replacing existing defaults.

Written by the indexing model from the issue text.