Teammates inherit a stale model after refusal fallback: spawn uses the main-loop override / mainLoopModel, not the session's effective model

Version: 2.1.280, macOS arm64. Observed on a build with unrelated local patches; no patch touches this code path.

What happened

1. A session on Opus 5.5 hit a model_refusal_fallback and was swapped to Opus 4.8.
2. About 20 minutes later the session's own turns returned to Opus 5.5: the model attachment and every assistant turn report claude-opus-5-5. There was no /model, /clear, resume or rewind.
3. Hours later, spawning a teammate (Agent tool, separate pane process) launched it with --model claude-opus-4-8. This happened both with no model and with an explicit model: "opus".

Expected: the teammate runs on the lead's effective model (Opus 5.5), and "opus" resolves to the current Opus.

Actual: the teammate runs on the fallback model. From reading the bundled source:

• The refusal swap writes both the main-loop override and AppState.mainLoopModel. Neither is unwound until /clear, a rewind or a session switch.
• New turns resolve their model from mainLoopModelForSession ?? mainLoopModel through the runnable-model filter, which is why the session runs 5.5.
• The spawn path reads the raw override when no model is given, and the raw mainLoopModel when a same-family alias is given ("opus" -> "same family as parent, reuse the parent's model"). So it inherits the stale 4.8.
• Net effect: teammates silently run on a model the lead isn't using, even when the caller names a model family explicitly.

Suggested fix: have spawn inherit the same effective model that new turns use, and/or have the refusal swap's restore clear the override and mainLoopModel once the session stops using the fallback.

Not determined: what moved the session's turns back to 5.5 at step 2. The exact trigger is unknown.