Session exit writes launch-time `model` back to settings.json, silently reverting edits (self-perpetuating stale default)

## Describe the bug

On exit, an interactive session writes its in-memory (launch-time) top-level `model` value back to `~/.copilot/settings.json`. If `settings.json` was changed after that session launched - by a manual edit, or by another session that is still open - the exiting session's write silently reverts the file to its own older value.

When the persisted `model` is one that is no longer in the account's catalog, this becomes a self-perpetuating loop: a clean launch falls back to the built-in default, and closing any older session re-writes the stale id back to disk, so hand-editing `settings.json` never sticks.

This is distinct from #4067 (model not applied on startup). Here the value IS applied on a clean startup; it is later clobbered on session exit.

## Affected version

1.0.75 (macOS, Darwin arm64)

## Steps to reproduce

1. Set `~/.copilot/settings.json` to `"model": ""` (any model; the loop is most visible if A is an id no longer in your catalog).
2. Launch session S1: run `copilot` (bare). It reads model A. Leave it open.
3. Edit `~/.copilot/settings.json` to `"model": ""` (a different valid model). Confirm the on-disk value is B.
4. Exit S1 (Ctrl-C twice, or `exit`).
5. Re-read `~/.copilot/settings.json`: the value has reverted to A. B is gone.

If A is not in the catalog, the startup log for step 2 shows:

```
[WARNING] Model '' from config file is unsupported or unknown. Falling back to default.
[INFO] Using default model:
```

The exit in step 4 rewrites `` (the launch-time value), not the resolved default, so the invalid id is preserved and the loop repeats on the next launch.

## Expected behavior

- Exiting a session should not overwrite `settings.json` with its launch-time model unless the user explicitly changed the model in that session (via `/model`).
- Edits made to `settings.json` while a session is open should not be silently discarded when that session exits.
- A `model` value that resolved to a fallback should not be re-persisted verbatim; persist the resolved model, or leave the file untouched.

## Impact

- Hand-editing `settings.json` to pin a default appears to "not work", because a lingering session overwrites it on exit.
- With a retired or unknown model id persisted, every new session silently downgrades to the default, and the file cannot be corrected while any older session is still alive.

## Workaround

Pass the model explicitly at launch so it does not depend on the file:

```
copilot --model --context --effort
```

A shell function wrapping `copilot` to always pass these flags is immune to the write-back.

## Additional context

- The `/model` picker also writes the top-level `model` and can reset `contextTier` / `effortLevel` to undefined, so using it interacts with the same persisted field.
- Related: #4067 (model not applied on startup), #3557 (contextTier not restored on startup), #1869 (model not persistent for future sessions).

Start at the session exit path that writes the top-level model to ~/.copilot/settings.json, then compare it with the /model picker persistence behavior. Reproduce the S1/edit/exit sequence from the issue and verify that an unchanged session no longer discards edits, while an explicit /model change still persists the intended value.

Written by the indexing model from the issue text.