A form's handler answers its own request, and a finished reply is finished

Two regressions, one of them much older than it looked.

htmx events bubble, and the composer's form declares `hx-on::after-request` so
it can clear itself after sending. Six things inside that form make requests --
the two scope switches, "ask me about these again", the agent mode select, the
effort select, and the jobs chip -- and every one of their afterRequest events
was reaching that handler. So changing the mode, or the effort, or toggling a
tool called `this.reset()` on a composer somebody was typing in and dragged the
view to the bottom. That has been true for as long as those controls have
existed. The jobs chip did not introduce it; it polls, so it made it happen
every five seconds, and that is the only reason it was ever noticed.

`event.target === this` is the whole fix, and it is what the attribute always
meant. Moving the chip out of the form would have left the other five.

The second: `steps.for_message` marked its trailing prose step as still being
written, so every finished reply ending in prose carried `msg__body--live` and
blinked a caret at the reader for ever. One flag was doing two jobs -- emit the
tail, and mark it live -- and a stored reply wants the first without the second.
They are separate arguments now.

Note what the existing test for that did: it asserted the caret was on the
*right* step, through `for_message`, and passed. It never asked whether a
finished reply should have one at all. It is driven through the live path now,
and the stored path has its own assertion.

The composer handler is driven under a DOM stub -- extract the body from the
template, fire the event from a descendant and from the form -- because a source
assertion can only say the guard is present, not what it does. Checked against
the bug before being kept: without the guard the stub reports the text wiped and
the thread scrolled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/web/templates/chat/_composer.html

@@ -48,7 +48,22 @@
           {% if chat %}
           hx-post="/api/chats/{{ chat.id }}/messages"
           hx-target="#thread" hx-swap="beforeend"
-          hx-on::after-request="if (event.detail.successful) {
+          {# `event.target === this` is load-bearing, and its absence quietly
+             threw away typed messages for releases.
+
+             htmx events BUBBLE. This form contains six things that make
+             requests -- the two scope switches, "ask me about these again",
+             the agent mode select, the effort select and the jobs chip -- and
+             every one of their `htmx:afterRequest` events reached this handler.
+             So changing the mode, or the effort, or toggling a tool, called
+             `this.reset()` on a composer somebody was typing in and dragged the
+             view to the bottom. The jobs chip did not introduce that; it polls,
+             so it made it happen every five seconds, which is what finally made
+             it visible.
+
+             A form's own handler answers its own request. Anything else in here
+             that fetches is somebody else's business. There is a test. #}
+          hx-on::after-request="if (event.target === this && event.detail.successful) {
             this.reset();
             document.getElementById('attachments').replaceChildren();
             window.lembas.autosize(this.querySelector('textarea'));