feat(models): add Claude Fable 5.1

[rynfar]

Adds Claude Fable 5.1 (claude-fable-5-1) support.

Supersedes #921 by @emaadshamsi, cherry-picked here to satisfy main's
signed-commit requirement (fork PRs sit at BLOCKED regardless of CI).
Their commit is preserved as-is; the second commit adds what it missed.

From #921

• claude-fable-5-1 becomes the canonical fable pin; claude-fable-5
  stays available as an explicit per-request pin
• /v1/models advertises Fable 5.1 with Max 1M context metadata
• bumps @anthropic-ai/claude-code — the older CLI rejects the model

Added here

bun.lock / bun.nix were never updated. #921 bumped package.json
and package-lock.json only, but CI installs with bun install from
bun.lock, and bun-nix-sync.yml verifies bun.nix matches it. That
workflow only triggers on bun.lock changes, so it was skipped entirely
on #921 — and CI's non-frozen bun install resolved the new version
anyway, so green checks hid a stale lockfile. bun install --frozen-lockfile would have broken on main after merge.

• pricing: claude-fable-5-1 and claude-mythos-5-1 as exact keys. The
  family fallback already priced them, but the settings page derives its
  overridable model list from the exact-key table, so both were missing there.
• tests: tier-mapping coverage for claude-fable-5-1 and
  claude-mythos-5-1 — neither id had any. Mythos 5.1 shipped alongside
  Fable 5.1 and rides the same alias.
• docs/agents.md: Fable 5.1 in the Crush and Droid example configs.
• comments: the fable branch describes a tier with several generations on
  one SDK alias, not just Fable 5.

The CLI bump is load-bearing

Not taken on faith. The 2.1.198 binary contains no claude-fable-5-1
string; 2.1.259 does. At runtime the old CLI returns:

API Error: 400 Claude Code 2.1.198 does not support this model;
version 2.1.251 or newer is required.

while claude-fable-5 still returns 200 on that same binary — so the
failure is model-specific, not a broken setup. The true floor is
2.1.251; ^2.1.257 clears it.

Not affected: forced tool choice

Fable 5.1 returns 400 on tool_choice any/tool. Meridian only reads
tool_choice client-side (the forceSingleToolUse capture-dedup
heuristic in server.ts) and never forwards it upstream — tools reach
Claude through the passthrough MCP server. Verified live below.

Testing

npm test: 2983 pass / 0 fail across 178 files, plus all 12 isolated
files green. npm run typecheck clean. (#921 reported a pre-existing
proxy-stale-uuid-retry failure; it does not reproduce here.)

Live E2E against Claude Max, proxy running the bundled 2.1.259 CLI:

Check	Result
/v1/models	9 models; claude-fable-5-1 at 1M ctx
Fable 5.1 non-streaming	200, model=fable[1m]
Fable 5.1 streaming	clean SSE envelope
Fable 5.1 tool call	stop_reason=tool_use, valid block
Tool result round-trip	end_turn, lineage=continuation
Legacy claude-fable-5	200 — no regression
Subagent mode	model=fable agent=subagent (no [1m])
MERIDIAN_FABLE_MODEL=fable	model=fable on a 5.1 request
claude-mythos-5-1	routes fable[1m], gated by account access
Bogus claude-fable-5-99	rejected — see below

The bogus-version check is the one that proves the feature is real: a
nonexistent fable version is rejected rather than silently served by
another model, which means the per-request pin genuinely reaches the SDK
and determines model selection. That is what makes claude-fable-5-1
succeeding evidence that Fable 5.1 actually served the request — the
failure mode this guards against is #529, where fable requests silently
answered as Sonnet.

Unrelated pre-existing issue (not fixed here)

An unavailable model returns HTTP 500 api_error rather than a 400 —
applies to claude-fable-5-99, claude-mythos-5-1, and the old-CLI
rejection alike. 500 is retryable, so clients will retry a permanently
invalid model. Adjacent to #919; worth a follow-up issue.

Closes #921.