fix(chat): drop the routing frame's block instead of emptying it

A user message that `@`-mentions an agent rendered correctly when it was sent
and grew a blank band under its text once the conversation was closed and
reopened. `append_agent_routes` appends the internal routing frame as its own
prompt block and the persisted prompt is the agent-bound one, so the stored turn
is two text blocks for every parser that keeps one block per recorded text item
— claude's, and codeg's own ACP transcript. The sanitizer emptied the frame's
block in place and only dropped a turn once every block was empty, so the turn
survived carrying a text block of `""`. That part draws nothing, but the
transcript stacks parts with `space-y-4`, and a zero-height sibling still takes
the gap.

The shared `RouteSanitized` decorator now removes a block the strip emptied
rather than leaving it behind. Only a block that actually held a frame is
eligible, so an empty text block a parser produced for its own reasons is left
exactly as found; the turn-level drop is unchanged, so a turn whose blocks all
go is still dropped as the transport-only record it was, while one left holding
an image is kept and still counted. The sanitizer runs at read time, so
transcripts already on disk are corrected on the next open.

`sanitize_text` also trims what it leaves behind. The strip absorbs a single
newline adjacent to the frame, so an agent that joins the prompt's text blocks
with a blank line left `"prose\n"` — one empty line under the message, the same
symptom in a different transcript shape. Text with no frame in it is untouched.

The renderer skips an empty user text part as a backstop. Assistant text is left
alone, since a streaming reply is legitimately empty before its first token
while a user turn is settled by the time it is drawn.

Codex is structurally immune to all of this, joining and trimming its prompt
text before it builds blocks, so none of it reproduces in a codex session.