Ignore subagent work, not subagent notifications

A subagent's tool calls do reach the parent session's hooks: measured, a
PostToolUse arrives carrying agent_id and agent_type. Only Stop was
guarded against that, and Stop was the case that mattered least.

With background subagents the ordering is the harmful one. The main agent
ends its turn first, so Stop lands and the session reads "waiting"; the
subagents keep working, and their PostToolUse arrives afterwards and puts
the session back to "busy". The panel then says a session is working when
its input line is free and it is waiting for you -- the precise confusion
this indicator exists to prevent, and reported from a live session doing
exactly that.

Every event carrying agent_id is now ignored. Synchronous subagents lose
nothing: the main agent is mid-turn, so its own earlier events already say
"busy".

Notification is deliberately exempt. It means a human is needed, and that
is as true when the agent that got stuck is a subagent -- ignoring it
would leave a session silently blocked.

Covered both ways in the hook tests, and checked once against a real
subagent event captured from a live run rather than a hand-written one.

hooks/claude-status-hook.py

@@ -83,12 +83,22 @@ def derive_state(event):
     name = event.get("hook_event_name")
     if name == "SessionEnd":
         return "end"
+    # A notification is honoured whoever raised it: it means a human is needed,
+    # and that is just as true when the agent that got stuck is a subagent.
     if name == "Notification":
         return NOTIFICATION_STATES.get(event.get("notification_type"))
-    # A subagent finishing its own turn is not the session becoming free; the
-    # main agent is still working. SubagentStop is a distinct event and is not
-    # registered, but Stop carries agent_id when raised inside an agent.
-    if name == "Stop" and event.get("agent_id"):
+    # Everything else describes work, and work done by a subagent is not the
+    # main agent's state. Measured: a subagent's tool call does reach the
+    # parent session's hooks, as PostToolUse carrying agent_id and agent_type.
+    #
+    # This matters most for background subagents. There the main agent ends its
+    # turn first -- Stop, so "waiting" -- and the subagents keep going, so their
+    # PostToolUse arrives afterwards and would flip the session back to "busy".
+    # The panel would then read "working" for a session whose input line is free
+    # and which is waiting for you, which is the exact confusion it exists to
+    # prevent. Synchronous subagents need no special handling either way: the
+    # main agent is mid-turn, so its own earlier events already say "busy".
+    if event.get("agent_id"):
         return None
     return EVENT_STATES.get(name)