…t field

Label failed edit_files calls 'Failed to edit' with the result error
text in the expanded view, matching the write_file error rendering, and
include the new errorText field in the execute render data unit test.

…wording

…promotion

… trim comments

…obbering newer server state

… error title

…ithout a cast

…iled request

…tion

…as newer

…erts

…esync

acceptServerChatStatus armed a resync that applied the currently cached
chatRecord.status immediately, so a failed send or edit could replace a
live websocket "running" with a stale REST "waiting" and make
shouldApplyMessagePart drop assistant parts.

The resync now waits for the chat query's dataUpdatedAt to advance past
the value captured when it was armed. Object identity does not work here
because TanStack Query structural sharing preserves the chatRecord
reference when a refetch returns value-equal data, which would leave the
resync armed forever and never apply an unchanged status.

Also covers the cross-chat send guard with an interaction story and drops
a store test that restated the guard instead of exercising it.

A status or error event arriving after acceptServerChatStatus armed the
resync but before the invalidated chat query resolved was overwritten by
the older REST status, which could strand the turn and make
shouldApplyMessagePart drop the retry's assistant deltas.

The resync now captures the server status version when armed and skips
the overwrite when the websocket advanced it in the meantime.

The send and edit failure paths armed a resync from the render that
started the request, so a rejection arriving after the user navigated
away captured the previous chat's dataUpdatedAt. The newly active
chat's higher cached timestamp then satisfied the freshness check at
once, overwriting a websocket-delivered status and clearing the
websocket-authoritative guard.

acceptServerChatStatus now ignores calls whose chat is no longer the
active one, which covers both failure paths at their single shared
entry point.

A send that promotes the queue head suppresses that ID locally, but a
concurrent queue mutation in another tab can leave the row queued
server-side, so the transcript and the queue both showed it until the
next authoritative snapshot.

The page now issues one uncursored messages request after the promotion
through a dedicated react-query key and hands the result to the store,
which clears the promotion markers and applies the snapshot in a single
transition. The store returns the queue it applied, so the caller caches
the filtered result rather than the raw response.

Stale applies are fenced on two axes: the convergence fence advances on
every accepted snapshot and whenever the active chat changes, and the
store drops a response whose originating chat is no longer displayed.
A send whose response lands after the user switched chats reconciles
from the queue currently cached for that chat, falling back to the
pre-send snapshot only when nothing is cached, so a queue update
received mid-send is not overwritten.

Three UAT defects in how the chat UI presents lifecycle hook outcomes.

A tool call blocked by pre_tool_use rendered as 'Ran <command>', as if it had
executed. Derive the failed wording from the tool-result error flag, matching
the write and edit tools. A command that ran and exited non-zero is not a
protocol error, so it keeps its existing wording.

A hook notice rendered above the message it annotates, which reads backwards
for a 'your prompt was rewritten' card.

Both hook outcomes on the create path fell through to the generic error alert,
so an expected policy decision appeared with a stack trace and a workspaces
action. Give each its own branch, keyed on the structured response body rather
than the status code so ordinary permission errors keep their treatment.