feat(doing): let an agent advertise what it is working on

[joy13975]

Why

hcom tells you whether an agent is awake, not what it is doing. status is a fixed lifecycle enum (active/listening/blocked/inactive/launching/error), and there is no field an agent can deliberately set to describe its current task. A peer deciding whether to interrupt, hand off, or wait has to open a transcript to find out.

This adds one verb so an agent can say it, and shows it everywhere the roster is already displayed.

hcom doing "refactoring the auth layer"   # set
hcom doing                                # show
hcom doing ""                             # clear

Peers read it in hcom list (inline, truncated to 50 chars), hcom list -v, hcom list <name>, --json, --format '{doing}', the TUI agent detail pane, and hcom events --type doing.

Why an event and not an instances column

• status_context / status_detail are rewritten by hooks on every tool-use tick, and set_gate_status explicitly overwrites status_detail unless it equals the one "cmd:listen" sentinel - so agent-authored text there does not survive. hints is reinjected into the owning agent's own message feedback and never appears in list output. notes is baked into the launch prompt once and is not a live field.
• No schema change: no SCHEMA_VERSION bump, no MIGRATIONS entry, nothing for existing databases to migrate.
• hcom list --stopped already derives current state from life events, so latest-event-wins is an established pattern here rather than a new one.
• Being an event makes it filterable and subscribable through the machinery that already exists.

A column would also have meant touching the positional-index instance_row_to_json, roughly 20 InstanceRow/Agent struct literals in test fixtures, and the TUI's separate hand-written query - about 30 sites for the same user-visible behavior.

The second commit is part of that reasoning rather than an afterthought: --type is a closed clap enum, so hcom events --type doing was rejected with invalid value 'doing' even though the rows were in the table. Adding the type to EventFilterArgs makes the filter, listen, and events sub all reach it, and there is a parse test so the event type and the filter enum cannot drift apart again. I found that by running the real bus, not by reading the diff.

Naming

doing, not intent: hcom send --intent request|inform|ack already means something different, and two unrelated senses of "intent" one space apart on the CLI would be a trap.

Notes

• An unregistered --name is rejected rather than recorded. Activity filed under a name no listing can resolve would be a silent no-op.
• The listing uses one grouped query for the whole roster rather than a lookup per agent. doing_map_from_conn takes a raw Connection so the CLI and the TUI snapshot loader share one definition of that query instead of two copies of the SQL.
• Both bootstrap primers (UNIVERSAL and SUBAGENT_BOOTSTRAP) mention the verb, and it is added to SAFE_HCOM_COMMANDS so agents are not prompted for approval on first use.

Testing

Unit tests in src/db/events.rs: round-trip, latest-wins including the empty-string clear, and that the per-instance map ignores other event types. Parse test in src/commands/events.rs for --type doing.

CLI smoke test in tests/cli_smoke.rs covering the full path: nothing-set message, set, read back, visible in list --json and --format, latest write wins, clear, and a second test asserting an unregistered name fails.

cargo test --test cli_smoke
test result: ok. 25 passed; 0 failed

End to end on a real two-harness bus

Not a CLI-only check: I launched a real headless Claude Code agent and a real headless Codex agent onto one bus at the same time, and had them talk.

$ hcom list
[CLAUDE]  * e2e-nene [headless]  now: listening - done - read peer transcript
[CODEX]   * e2e-kobe [headless]  now: listening

$ hcom list --format '{name} [{tool}] doing={doing}'
e2e-nene [claude] doing=done - read peer transcript
e2e-kobe [codex] doing=codex side - set via absolute path

$ hcom events --type doing --last 10
  nene -> claude side of cross-harness test
  nene -> done - read peer transcript
  kobe -> codex side - set via absolute path

Both agents set their own doing through the CLI, and each read the other's conversation via hcom transcript. The messages went both ways (intent=request from the claude agent, intent=ack back from the codex agent). Against the released 0.7.25 binary the same events --type doing query fails with invalid value 'doing', which is the before-state for the second commit.

Also verified in the TUI rather than by inspection - the agent detail pane renders:

  o hera - adhoc - 4s - doing                                    created 5m
  ~/code/mew
  doing: verifying the TUI renders this

cargo fmt --check and cargo clippy -D warnings are clean via just ci.

Note on the local suite

cargo test on my machine has 17 pre-existing failures in hooks::gemini::tests (all asserting setup_gemini_hooks(false)). They fail identically on unmodified main at 79ebde1 - I diffed the failing node-id sets in both directions and they are the same set, so they are unrelated to this change. They look environment-specific, and CI here is green. Everything else passes: 2161 passed, and the full cli_smoke suite is green.