needs_action is wired but nothing populates it — proposal: client-side attention projection over existing events (+ WF-08 completion)

[VenusOne-Lee]

What we found

The feed's needs_action category is wired end-to-end but nothing can ever populate it:

• crates/buzz-db/src/feed.rs:167 defines needs_action as kinds 46010/40007 p-tagging the user.
• Nothing in the tree emits either kind. The WF-08 TODO at crates/buzz-workflow/src/executor.rs:663 suspends workflow approvals without emitting 46010.
• 46010 is absent from required_scope_for_kind() in crates/buzz-relay/src/handlers/ingest.rs, so a client cannot submit one even deliberately.

Net effect: needs_action returns an empty list on every surface (relay SQL, desktop Tauri mapping, mobile). The slot exists and waits; no producer exists. (File references are against 28ae6cd2.)

The user problem behind it

Operators running several agents get a feed that answers "what happened" but not "what is stuck on me". Asks for a decision, an approval, or a manual step drown in ambient activity, so agents block on a human who cannot see that they are the blocker. VISION_ACTIVITY's own framing applies: waiting should be a rendered state, and a polished view should be a zoom level on the same truth, not a different feed.

Proposal (for discussion before any feature PR)

A client-side attention projection over events the relay already stores, rather than a new pipeline:

• Projects only mention and actionable-ask items from the existing feed (layered on buildInboxItems); ambient activity excluded by construction.
• Deterministic, pure-function ask extraction (no model calls, unit- and regression-testable).
• Every resolution posts an ordinary threaded kind-9 reply p-tagging the asker, so the asking agent wakes through today's trigger path. Nothing is resolved silently.
• Zero new event kinds, zero relay changes — consistent with VISION_PROJECTS ("custom kinds only where genuinely novel").
• Ships behind a preview-features.json flag, off by default.
• Packaging lean: an Inbox mode/section rather than a fourth sibling surface, per the precedent in feat(desktop): handle project work from Inbox #3117.

Separately and complementarily: completing WF-08 so workflow approvals emit 46010 would give the reserved category its first real producer. We are happy to take that on as its own thread of work.

Evidence this is buildable small

We built this in our fork (VenusOne-Lee/buzz, branch buzz-one) and have been using it daily against a live community relay: projection library, deterministic extractor with regression tests reproducing real field misclassifications, five posting actions with a client-side undo before publish, all behind a preview flag. Current suite: 3832 unit tests plus Playwright coverage of the full card lifecycle.

If the direction is agreeable we would split it into small, independently mergeable PRs:

1. Pure projection library + full unit/regression suite (no UI, no routes).
2. The rendering consuming the library, unreachable without the flag.
3. Nav entry + the flag definition, off by default, with screenshots.

None of these touch the relay or add kinds. Is this a direction you'd merge, and do you have a preference on the Inbox-integrated packaging versus a separate gated screen?