Devin's model picker is empty when `devin models list` fails — fall back to the ACP configOptions Bench already reads

## What is wrong

#114 landed the Devin model picker, and it works — but on this machine today it shows nothing to
pick. The family list is read from `devin models list --format json`
(`src/daemon/devin-models.ts`), and that command is failing:

```
$ devin models list --format json
Error: Connection failed: Connect HTTP error: HTTP error: error sending request for url
(https://server.codeium.com/exa.api_server_pb.ApiServerService/GetCliModelConfigs)
```

It has failed on every attempt across two days, while `devin auth status` says logged in and plain
HTTPS to `server.codeium.com`, Anthropic and GitHub all answer. `devinFamilies()` degrades safely
to `[]`, which is the right failure — but the developer is then offered only "Account default",
which is exactly the state #114 existed to fix.

## The fix is a source Bench is already reading

The ACP `session/new` result carries the whole list, unasked. Measured on this machine, at the same
time as the failures above:

```
DEVIN_MODEL=fusion -> currentValue=fusion-claude-fable-5-1-medium-sidekick-swe-2-medium (options: 385)
DEVIN_MODEL=adaptive -> currentValue=adaptive (options: 385)
DEVIN_MODEL=(unset) -> currentValue=swe-2-high (options: 385)
```

**385 options, over a path that works while the CLI RPC does not.** And `devin-session.ts` already
parses that exact block — `modelOptionValueFrom()` reads `configOptions` for
`{id: "model", currentValue}` to show what a session resolved to. The options array sitting beside
that `currentValue` is the list the picker wants.

#114's ticket named both sources. Only the CLI one was implemented, which is reasonable — it is the
cheaper of the two, needs no session, and the other was not known to be the survivor at the time.

## Acceptance criteria

- [ ] When `devin models list --format json` fails or returns nothing, the picker still offers
Devin's families, sourced from an ACP `session/new` `configOptions` block.
- [ ] Families, not the 385 raw variants — same grouping the picker already shows. The variants
carry their family in the name (`claude-opus-5-high`, `gpt-5-6-luna-max`), and `adaptive` and
`fusion` are single-entry families, so whatever derives the grouping must not drop those.
- [ ] Opening a throwaway ACP session purely to read the list is acceptable, but it must not be
done on every request — `/api/devin/models` is deliberately uncached today because the CLI
call is cheap, and a session handshake is not.
- [ ] Both sources failing still degrades to "Account default" only, as now.
- [ ] A test covers the fallback firing when the CLI source returns nothing.

## Out of scope

- Changing what #114 built when the CLI source does work.
- `session/set_config_option` — changing the model on a live session without a restart. Still its
own ticket.
- Diagnosing why `GetCliModelConfigs` fails. That is Cognition's endpoint, not ours, and this
ticket exists precisely so it stops mattering.

## Verification

```
pnpm test
pnpm exec tsc -p tsconfig.json --noEmit && pnpm exec tsc -p tsconfig.client.json --noEmit
```

Manual check a green build will not catch: with `devin models list --format json` still failing,
open the model dialog and confirm Devin's families are listed — `adaptive` and `fusion` among them.

## Related

- #114 — built the picker and the CLI-backed source.

Start with src/daemon/devin-models.ts and the /api/devin/models path, then read devin-session.ts, especially modelOptionValueFrom() and its configOptions parsing. Trace how devinFamilies() currently handles an empty CLI result and run the existing tests with pnpm test. Done means the ACP fallback supplies grouped families, including adaptive and fusion, without opening a session on every request, while both sources failing still leaves only Account default.

Written by the indexing model from the issue text.