Feature: surface the resource wishlist in its own dashboard tab

Request (operator, verbatim)

"make a note for the end of the test that i want the 'resource wishlist' in a seperate tab so i am quickly notified when you want stuff from me, i think thats really good and now i ran into it by accident"

Why

session(action="wishlist_add") is explicitly non-blocking by design, which is right — the agent should keep testing rather than stall. But the consequence is that a fulfillable request can sit unread for the entire engagement, because nothing surfaces it.

In this engagement three items sat unseen in wishlist_queue.json:

wish-23b8e6be blocked the blast-radius question on the engagement's only High finding (could an ordinary care worker forge medical-note authorship, or only an application administrator?) for about a day. It was resolvable in minutes once the operator saw it — and the operator only discovered the wishlist existed by accident.

Proposal

• Dedicated dashboard tab for the wishlist, with an unread badge on the tab header.
• Show need, category, rationale, and the count of blocking_cell_ids.
• Per-item Fulfil / Decline action; fulfilling re-opens the cells the item was blocking (the backend already supports this).
• Optional: a toast or notification on the first wishlist_add of a scan, so the operator learns the tab exists.

Start by tracing the dashboard and the session(action="wishlist_add") flow, then inspect wishlist_queue.json and the existing backend support for fulfillment. Implement a dedicated wishlist tab with an unread badge, the requested item fields, and Fulfil/Decline actions. Done means fulfillment reopens blocked cells and the optional first-scan notification is addressed or explicitly excluded.