fix(settings): accept the image model a signed-in vendor account offers

[vastsa]

Problem

Settings > Models > Image generation model lists the image model a signed-in
ChatGPT (Codex) account answers with (gpt-image-2.5, gpt-image-2), but
picking one saved nothing: no toast, no write, and the menu stayed at its
placeholder.

Root cause

A vendor account's image model is deliberately never stored in
provider.models — the account's chat routes do not serve it — so it reaches
the picker only through vendorAccountImageCandidates(). The picker row
composed its options from the stored candidate list plus those vendor
candidates, while setImageGenerationDefault validated the choice against the
stored list alone. With no candidate list stored yet (a fresh install),
settings.imageGenerationModels contributes nothing, isImageCandidate
returned false, and the handler returned silently.

Reproduced against a local data dir holding a signed-in OpenAI (ChatGPT Plus/Pro) row (vendorKey: openai-codex, authKind: oauth, credential
present) and imageGeneration: null:

before, candidates = []
before, gpt-image-2.5 accepted = false
after,  candidates = [{providerId: <account>, modelId: "gpt-image-2.5"}, {... "gpt-image-2"}]
after,  gpt-image-2.5 offered and available = true

Change

• components/settings/image-generation-default.ts: new
  imageGenerationPickerCandidates(stored, active, providers) — the single
  composition of stored candidates, the legacy single-binding fallback, and a
  signed-in vendor account's image model — plus
  isImageGenerationPickerCandidate.
• ImageGenerationModelRow.tsx: renders its options from that helper.
• ModelConfigPage.tsx: validates the choice against the very same list, and
  the chat-model exclusion reuses one membership predicate instead of a local
  copy of the same rule.
• Tests: the candidate list is pinned (vendor account offered, signed-out
  account and other vendors refused, an explicitly cleared list is not
  resurrected, the legacy fallback still applies) and a contract test holds the
  row and the page to the same helper. Two stale source assertions were updated.

No other behavior changes: an explicitly cleared candidate list still does not
come back, a missing list still falls back to the legacy single binding, and
the row's availability rules are untouched.

Verification

Task-candidate run in the dedicated worktree on 278e929ca (origin/main):

• node --test test/*.test.mjs (apps/desktop) → 3591 pass / 0 fail
• tsc -p tsconfig.json --noEmit (apps/desktop) → clean
• check-style-tokens, biome lint, check-architecture,
  check-agent-policy-sync, check-release-docs, check:pr-base → pass
• electron-vite build → OK

Not run: UI E2E (verify:ui:*); the change is renderer-only and the affected
surface is covered by the tests above.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.