feat(observability): session capture must ship with the CLI — today it's an hq-local hook, and every session gets the same anonymous label

[agents-squads]

Problem 1 — product gap

Interactive-session observability (sess_* rows) is implemented as a hook script living in OUR hq repo (.claude/hooks/xeu-session-events.mjs), wired by hq settings. A user who runs squads init gets lane/dispatch observability (that IS in the CLI) but zero session capture. Violates the core rule: if it only works for us, it's a bug.

Problem 2 — anonymous, indistinguishable rows

The hook stamps EVERY session squad=hq, agent=chief, brief='interactive Claude Code session'. Any script that shells out claude -p (fan-outs included) creates N sessions that all render as identical 'interactive Claude Code session' rows — on the board this reads as duplicated sessions. Verified live: 5 parallel haiku one-shots at 13:36:18Z (a briefing-generator fan-out) all labeled as interactive chief sessions. This is the 'sessions masquerade as squad work' trust violation (api#273 family).

Scope

1. Bundle the session hook with squads-cli (script asset) and have squads init (or squads services enable sessions) install it into the project's .claude/settings.json, pointed at the user's own local API. Squad/agent identity comes from the instance config, not hardcoded 'hq/chief'. Pure capture/stamp/transport — no valuation logic in the hook.
2. Brief from the first user message (same derivation as deriveRowForSessionFile, cli#1165), capped 200 chars — rows become distinguishable.
3. Classify session kind at capture: interactive vs one-shot (claude -p) — stamp in extra_data so feeds/boards can group or filter noise instead of rendering N identical 'interactive' rows.

Related: cli#1170 (closed — model/token carriage), api#260 (zero-token feed filter), app#206/#207 (drill surfaces).