Report a backgrounded command into the card that launched it

A backgrounded command has no subagent, so there is no second transcript for
its report to live in and its own tool card is the only record of it anywhere
-- and until the task notification arrives that card is showing the launch
result, which says the command is running. It was left saying that for ever.

The report now updates the call's own row (`Event::ToolUpdate` against its
tool_use id), so the card ends up holding what became of the command instead
of a claim nothing was ever going to correct. That includes the endings that
carry no summary: those are exactly the ones that went wrong, and a stale
"running in background" reads worst on them, so they say the status word
rather than nothing. A task with a subagent behind it is untouched and its
report stays where it was, in that subagent's own transcript.

Echo grew `/background [seconds]` for the shape end to end: the Bash call, the
launch result, a turn that ends `waiting`, and the completion arriving later
to correct the card and start a second turn.

Verified on the emulator: the card reads `Background command "sleep 5 && echo
done" completed (exit code 0)` where it had said "Command running in background
with ID: ...". 172 server tests, ktfmt, clippy, rustfmt, Android lint and the
JVM unit tests clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SUBAGENTS.md

@@ -86,7 +86,10 @@ transcript is still being written to and its process is the session's to stop.
    of dividers about work the reader was not asking after; the closing report
    is *this* transcript's last line and here is where somebody reads it. What
    the parent gets a row for is a message a subagent genuinely sends it, which
-   arrives by the peer path. The two lifecycle shapes are still handled once:
+   arrives by the peer path. A backgrounded *command* is the other half of
+   this and goes the other way: it has no transcript of its own, so its report
+   updates the tool card that launched it, which was still saying the command
+   was running. The two lifecycle shapes are still handled once:
    whichever gets there first is the one that finds the task still open, and
    `finish` below closes it. See PLAN.md's "Two turns must never be drawn as
    one".