kennel status: redesign per-repo display — worker summary + issue + PR + worker thread + webhook list, claude stats on the talker, no 'Doing:'

[FidoCanCode]

Replace the current kennel status per-repo block with the layout below. The Doing: line is removed entirely.

Layout

Each repo emits exactly these lines, in this order:

1. Worker summary — <repo>: fido <state> — <compact stats>. If nobody is currently talking to claude for this repo, claude stats (pid, uptime, session-alive) attach inline to this line.
2. Issue: #N — <title> (elapsed Xm)
3. PR: #N — <title> (when a PR exists)
4. Worker thread details — the worker thread's own state (idle / in-session / waiting on approval / waiting on CI / waiting on threads). If the worker thread is the one talking to claude, claude pid/stats attach to this line.
5. Webhook threads — indented list, up to 5 entries, plus +N more summary line when there are more than 5. Each line: description + elapsed. If a webhook thread is the one talking to claude, its line sorts to the top of the webhook section and claude pid/stats attach to it.

Exclusivity invariant (already landed in #475)

At most one thread per repo may be talking to claude at any moment. Concurrent registration raises ClaudeLeakError → os._exit(3). So the display only ever has to show claude stats on one line per repo. If we ever want to show two, that's a bug — halt loud.

Changes this ticket owns

• Remove the Doing: line from _format_repo_body entirely
• Read the active ClaudeTalker (already exposed in /status since ClaudeTalker registry + session_alive + halt on leak (closes #473) #475) and route claude stats to the correct line:
  • kind=worker → worker thread details line
  • kind=webhook → that webhook's line, sorted to top of the webhook list
  • none → inline on the worker summary line
• Cap webhook list at 5 with +N more overflow
• Fix the pgrep-vs-persistent-session mismatch by using the kennel-tracked pid (expose via /status payload, drop the pgrep lookup)
• Separate worker-thread worker_what from webhook-thread activity — the two had been multiplexing through the same field, causing the old Doing: handling webhook action noise

Out of scope

Actually routing webhook handlers through the persistent session (so register_talker webhook-kind entries go away) — that's separate follow-up work. This ticket only makes the display honest about what's already happening.