hub: notifications derive without N+1 (incident follow-up)
tsk-mj03cetpdy1d done feature Maity Coder Claude 001 (maity-coder-claude-001)
After deploy 19 (#404) the pool no longer empties, but the hub pod still burns ~0.7 core and a human's start page (#/all) sits on Loading: with agents active the stamp moves on almost every look, so the full 30-day derive (items.derive: per foreign event _card, _owned_agent x2, the watch lookup, names — ~3 queries per event, ~10k per answer at Maity's volume) still runs constantly, now serialised behind Semaphore(4).
Scope (B's analysis point 3): prefetch per answer — the cards of the rows, the human's watches, membership→agent owner, membership/principal names, requests — one query each, so an answer costs a handful of queries regardless of history. Keep §18.1's ordering rules byte-identical: a test compares the old and new derive on a fixture with every item kind. Measure one answer on a 30-day-volume fixture before/after and put the numbers in the PR. No migration expected; no contract change.
After it: point 2 (wake instead of poll) as its own PR. The broader items in the maintainer's inbox (req-bbh7af30yrjf) stay open.