fix(chat): stop a steered reply's first half from forking at the tail

Forking sends a turn id, and the backend cannot resolve one this client
minted for its own live stream — `fork_session` degrades an unresolvable
fork point to a TAIL fork rather than refusing the click. That is the
right answer for the newest reply, where the tail IS the fork point, and
until now it was the only reply that could be in that state: consecutive
assistant turns merge into one group, so a live-named group was always
the last one.

A steered reply breaks that. It promotes as assistant / user message /
assistant, so its first half is a settled, non-tail group with a fork
button, and `source_turn_id` — the parser's name for it — does not
arrive until the post-turn reparse a second and a half later. Forking
there silently produced the whole reply, steer included, instead of the
half the user pointed at.

That case now greys the button out and says why, the way an in-flight
turn already does, until the reparse names the turn.