The composer pills, the permission level and the retrieval controls were
installation-wide, so switching chats carried one conversation's modes into the
next, and reopening an old chat showed whatever the defaults happened to be.

Sixteen of those settings now travel with the thread. chat_threads gains a
settings_json column, ChatThreadSettings pins the contract PATCH
/api/chat/threads/{id} accepts, and thread-scoped-settings.ts re-validates every
value against the same literals and ranges before it is sent.

Editing one of them with a chat open writes the snapshot onto that thread and
leaves the installation defaults alone. Editing with no chat open still moves
those defaults, which every chat without a snapshot follows, so a fresh install
behaves exactly as before. A chat that stored nothing is pinned on first open,
so a later change to the defaults cannot rewrite its modes. Full access stays
session-only: the sanitizer drops it, and a write made while it is active
carries through the level the chat already held.

resolveToolsEnabledOnLoad, setBypassPermissions, setDeepResearchEnabled and both
external-provider effects in chat-page.tsx read the open chat's value before the
installation one, so a model load or a model switch no longer re-applies the
defaults over the pills a chat is running with. A thread that stores no value
for a setting falls back to the defaults rather than to the outgoing chat's.

upsert_chat_thread COALESCEs the column, so the writers that rebuild a thread
record cannot clear it; fork_chat_thread copies it; and list_chat_threads leaves
it out, since the sidebar lists every thread and only an opened one reads it.

normalizeStoredPermissionMode moves the legacy confirm-toggle migration out of
the store so it can be pinned directly. Once the level is mirrored to
/api/chat/settings the first hydration seeds it there, so the mapping can no
longer be driven through the UI more than once per installation.

…ents only

Two problems found while simulating upgrades, downgrades and the three browser
engines against this branch.

settings_json is the first strictly validated nested model Studio builds out of
the database rather than off the wire, and a stored snapshot outlives the build
that wrote it. A newer Studio adding a setting, widening an enum or raising a
bound writes a blob this one rejects, and refusing it 500s the chat on open, on
fork and on patch, and takes GET /api/chat/export down for every chat, not just
the affected one. _json_loads already shrugs off JSON that will not parse, so
JSON that parses but postdates this build now gets the same treatment: rows go
through thread_from_row, which drops what it cannot read. Only the read is
forgiving. Both wire models stay extra = forbid, so a client still cannot invent
a setting, and the row is left untouched, so upgrading again restores it.

The unload flush also ran on visibilitychange, which is not terminal: it fires on
every tab switch and the page carries on afterwards. That path used the keepalive
beacon, which PATCHes the row directly and answers 404 for a thread whose row has
not been created yet, while having already consumed the pending write. Terminal
events keep the beacon; visibilitychange takes the normal path, which creates the
row first and which the page is still alive to await.

tests/studio/sim_thread_settings_portability.py covers the migration against a
populated pre-existing database, idempotency, the COALESCE preservation, unicode
and emoji and Windows-shaped paths through the column, WAL, and the SQLite floor.
It is stdlib only, so it runs on Windows and macOS as well as Linux.

…r-broad guards

Six items from the review, all reproduced against the code at head first.

The composer is live while a chat's settings are being read, and until they land
the store still holds the OUTGOING chat's values. snapshotQueuedChatRunSettings
captures permissionMode at send time and sends it as permission_mode for the whole
run, so a send in that window really does run under the previous chat's level, and
a rejected read left those values up indefinitely. The store now drops to the
installation defaults for the duration of the read, which is the only honest thing
to show for a chat whose own settings are not known yet.

Edits made during that window were still held, but the switch-away path replayed
them into the installation defaults, which is the leak the holding exists to
prevent. They are now committed to the thread they were made in; the values are
still in the store at that point because the incoming chat's read has not resolved,
and a chat with no row writes nothing, so an unsaved chat stays on the defaults.

activeThreadScopedSettings was only refreshed when the debounce built its payload,
so for 400ms after an edit neither it nor localStorage carried the new value. A
model status poll landing there reverted the pill and the pending write persisted
the revert. threadScopedOverride now prefers the live store while a captured write
is pending; a pending pin keeps its own snapshot.

Snapshot writes are chained per thread. The backend replaces settings_json rather
than merging it, so two unordered writes do not merge, they pick a winner.

Two guards were too broad. A chat first opened under Full access was pinned with no
permission level at all and then followed the installation one forever; it now
records the level underneath. And the deep research guard refused every external
checkpoint, while externalCheckpointRefusesDeepResearch already exists and treats
openai_codex as supported, which is the rule the composer follows.

…on window, and two restore constraints

- await this chat's in-flight snapshot PATCH before reading it back, so a
  chat edited, left and re-entered does not get its pre-edit snapshot applied
  over the values the user just set
- keep the chat paired after a failed thread read, with a bounded retry, so
  later edits in it stay thread-scoped instead of moving the installation defaults
- give each per-thread write a ticket so a queued write cannot land after the
  unload beacon and restore the older snapshot
- start holding a chat's edits as soon as its id is known, not once
  /api/chat/settings has hydrated; the composer is interactive in between
- keep Search and Thinking mutually exclusive on Kimi when restoring a snapshot
- keep a stored Search/Code preference that a tool-less model has clamped off

…write races

- send only the edited fields, merged onto the row's own snapshot, when a chat's
  read never landed; the full replace was erasing settings the user never touched
- release a held edit as soon as the first read says the row does not exist,
  instead of waiting for an unrelated history event
- keep global hydration off a field whose edit is still held for its chat
- keep a held edit out of the captured installation defaults
- preserve a clamped Images and Fetch preference too, not just Search and Code
- abort a settings PATCH that is already out when the unload beacon supersedes it

…that waits for them

- PATCH gains settingsPatch, which applies only the fields it names. The unload
  path and the commit-on-leave path use it: both know what changed but not what
  else the row holds, and a replacement built from the defaults on screen was
  erasing the rest of the chat's snapshot
- a replacement now keeps whatever the writing client could not read, so an older
  Studio opening a newer database no longer deletes the settings it had to drop
- flush an edit held during pairing on a terminal event, keepalive, instead of
  relying on effect cleanup that unload does not guarantee
- a legacy Dexie fallback means the backend read FAILED, so retry and keep the
  chat paired rather than releasing its edits to the installation defaults
- park a send while the chat's own settings are still on their way, reusing the
  existing wait-and-send path, so a chat stored as ask cannot run on a global off

for more information, see https://pre-commit.ci

…first

The Search and Code pills are disabled while a model that cannot run tools is loaded,
and this test drives both. The CI job it was added to leaves a small GGUF resident from
an earlier step, so every pill click timed out on a disabled button: the test failed for
a reason that has nothing to do with what it checks. Unload first, which is also the
state the test is about, since with nothing loaded the pills stay pre-selectable.

Found by running the job on a staging repo while the org queue was backed up; this step
has never actually completed on this PR.

- release a chat's pairing gate only for that chat. The previous round held them per
  chat but resolved every one on any settle, so a run started for A was still freed
  by B's pairing ending. Leaving a chat mid-read now leaves its gate shut, since its
  snapshot never arrived, and the wait is bounded so a run cannot hang on it
- clear a thread's replay entry once a write of this session's lands. The entry
  carries the previous session's writer id, which the server will not order, so a
  retry could revert settings changed since
- bound each replay request. Every settings write waits on them, so one socket that
  never settled left the session unable to persist anything
- keep a failed write tracked, so a terminal event still beacons it. Dropping it left
  nothing to resend and the edit came back reverted
- let a failed snapshot write reach the fork, which now stops rather than making a
  fork that carries the pre-edit modes

Six more invariants pinned, all six failing on the previous revision.

An unsaved chat carries an assistant-ui runtime id (__LOCALID_...), which no row
exists for, so its settings read can only 404. Holding edits behind that certain
failure meant a pill or permission level chosen on a fresh /chat did not reach the
installation defaults until the round trip came back, and playwright_chat_ui asserts
it is there immediately: 'Run automatically persisted ask, expected off'.

That test is untouched by this PR and passed at an earlier revision of it, so this is
a regression the branch introduced. Found by running the suite on a staging repo while
the org queue was backed up.

The UI workflow boots this server on the Studio home the chat-ui and
cross-browser permission tests have already driven, so the install is shared
rather than fresh and arrives carrying whatever level they left in the mirrored
settings. Every assertion in the file names a literal level, so the run failed
on staging with the composer showing Run automatically where Approve for me was
expected, before a single per-chat assertion had been made.

Set the default from the unsaved chat the test already starts on, where no chat
is open and the edit is the installation's, and print it.

Four fixes from review:

- Each pairing read now carries its own deadline and controller. bounded: true
  is the 30 second WRITE timeout, so the losing side of the 8 second race stayed
  open while the retry opened the next one, up to three per chat during an
  outage, and leaving the chat cancelled none of them.
- The ensure step in front of a settings write is bounded and takes the caller's
  signal. It runs before the write, so neither the signal nor the write timeout
  reached it, and a stall there left the per-thread chain pending for the life of
  the page with reopening and forking that chat waiting on it.
- A default hydration skipped because its field was held is kept and used when
  the pairing window closes. The restore was falling back to the pre-hydration
  copy, so snapshot-less chats followed this browser's stale value rather than
  the server's until a reload.
- Tab-close snapshots are replayed even when /api/chat/settings fails to
  hydrate. They are rows' own settings and have nothing to do with that
  endpoint; the replay is guarded so it still runs once.

Also documents why a refused settings write does not roll the metadata in the
same PATCH back: a refusal means this writer already landed something newer, not
that the write failed.