GOOSE_SUBAGENT_MODEL/PROVIDER override recipe settings.goose_model/goose_provider

**Describe the bug**

`resolve_provider`/`resolve_model_config` in `crates/goose/src/agents/platform_extensions/summon.rs` resolve `GOOSE_SUBAGENT_PROVIDER`/`GOOSE_SUBAGENT_MODEL` above everything else, including `recipe.settings.goose_provider`/`goose_model` (`summon.rs:1726`, `summon.rs:1822`). #9650 introduced this to stop the orchestrator LLM from confabulating provider/model into `delegate()` tool-call params (#9644) and having the env var silently ignored. It also put the env var above `recipe.settings`, not just above LLM-supplied params.

This contradicts goose's own documented precedent for the sibling variable. `GOOSE_SUBAGENT_MAX_TURNS` is documented as "can be overridden by `settings.max_turns` in recipes" (environment-variables.md:156). Recipe settings outrank that env var. It also contradicts the Settings section's own note in recipe-reference.md: "Settings specified in a recipe will override your default goose configuration." Neither `GOOSE_SUBAGENT_MODEL` nor `GOOSE_SUBAGENT_PROVIDER` appears in the docs at all, so there's no documented precedence for the reversal. This looks like an oversight in #9650's scope, not a deliberate design choice.

Net effect: any recipe that pins a distinct `goose_model`/`goose_provider` per delegate role has every role silently collapse to one model the moment `GOOSE_SUBAGENT_MODEL` is set anywhere in the environment. No error or warning is raised.

---

**To Reproduce**

Steps to reproduce the behavior:
1. Two recipes, each with a documented `settings:` block (per recipe-reference.md#settings), same provider, different model:
```yaml
# role-a.yaml
settings:
goose_provider: "openrouter"
goose_model: "openai/gpt-5.6-luna"
```
```yaml
# role-b.yaml
settings:
goose_provider: "openrouter"
goose_model: "google/gemini-3.8-flash"
```
2. `export GOOSE_SUBAGENT_MODEL=anthropic/claude-opus-5`
3. `delegate()` into role-a, then role-b, from an orchestrating recipe.
4. Both delegates run on `claude-opus-5`. Each recipe's own `goose_model` is silently ignored.

---

**Expected behavior**

`recipe.settings.goose_model`/`goose_provider` should not be overridden by `GOOSE_SUBAGENT_MODEL`/`GOOSE_SUBAGENT_PROVIDER`. This should match the precedence already documented for `GOOSE_SUBAGENT_MAX_TURNS`: subagent tool-call param > recipe `settings` > `GOOSE_SUBAGENT_*` env var > persisted config > default. Whatever the final order, it should be added to environment-variables.md and recipe-reference.md. Both vars are currently undocumented.

---

**Screenshots**

N/A

---

**Please provide the following information**
- **OS & Arch:** macOS (Darwin 25.6.0) arm64
- **Interface:** CLI
- **Version:** v1.49.0 (commit dce690095)
- **Extensions enabled:** N/A
- **Provider & Model:** Any. Reproduces with any provider/model pinned via recipe settings.

---

**Additional context**

Related: #9644 (orchestrator LLM confabulation into delegate() params), #9650 (introduced this regression while fixing #9644). Code: `summon.rs:1718` (`resolve_model_config`), `summon.rs:1809` (`resolve_provider`). The regression is currently pinned by an existing test that asserts the overriding behavior as intended: `test_resolve_model_config_env_var_overrides_recipe_model` (`summon.rs:3246`). That test's assertion should be reversed if this is addressed.

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).