Explore: cards can be dragged out to the inbox

One-directional drag support, joining the shared "kanban" group:
put: false and sort: false mean a card can leave Explore's list (to
unfile it via the sidebar's inbox) but the list can't receive a drop
itself (there's no status to assign an incoming card) or be reordered
by dragging (it's sorted by name regardless).

sortedCards moves from a computed to a ref rebuilt by a watch --
<draggable> splices its bound list in place as the user drags, which a
plain computed would just discard on its next recomputation. No local
@change handler is needed: the splice already happens locally, and the
inbox's own handler (AppSidebar) persists the move and reloads this
project's cards regardless of which side of the drag it's reacting to.

AppSidebar: widened the "is a project open" check for the post-drag
cards refresh back to both project routes (Explore's list is now also
a place a card can leave from), and reused the same route-name set
already defined for the sidebar's project switcher.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

web/README.md

@@ -160,21 +160,31 @@ project) the way switching to a different project's id still does.
 ### Explore
 
 The flat card list, **sorted by name (case-insensitive)** via a `sortedCards`
-computed — there is no manual order here. Each row links to the card's own
-view (`/cards/:id` — see [Card detail](#card-detail)) and shows its status
-chip (`card.status.name` or "No status") next to the text; a delete button
-sits outside that link.
+ref (rebuilt by a `watch` on the store's `cards.cards` -- a plain computed
+can't be handed to `<draggable>`, which splices its bound list in place as
+the user drags). Each row links to the card's own view (`/cards/:id` — see
+[Card detail](#card-detail)); there is no manual order here, and no delete
+button either -- deleting lives on that view now.
+
+The list is a `<draggable>` too, but one-directional: `group: { name:
+'kanban', put: false }` and `sort: false` mean a card can be dragged *out* --
+to the sidebar's inbox, unfiling it from the project -- but Explore can't
+receive a drop itself (there's no status to put an incoming card in), nor
+reorder on its own drag (it's sorted by name regardless). No `@change`
+handler is needed on this side: `<draggable>` already splices the card out of
+`sortedCards` locally, and the inbox's own handler (see above) persists the
+move and reloads this project's `cards`, which rebuilds the list from the
+authoritative result regardless of which side reacted to the drop.
 
 ### Kanban
 
 One column per project status, in `position` order -- the inbox is *not* a
 column here; it's in the sidebar (see above), though it's still a valid drag
-source/target (the only view where that's true -- Explore has no draggable
-list of its own, which the sidebar accounts for when deciding whether to
-refresh a project's cards after an inbox drag). Unlike the cards, statuses
-are this route's own fetch (`GET /api/projects/:id/statuses`) -- Explore has
-no use for them. `board` is derived from `cards.cards` + those statuses and
-rebuilt by a `watch` whenever either changes.
+target as well as a source (unlike Explore, which can only send a card *to*
+the inbox, not receive one). Unlike the cards, statuses are this route's own
+fetch (`GET /api/projects/:id/statuses`) -- Explore has no use for them.
+`board` is derived from `cards.cards` + those statuses and rebuilt by a
+`watch` whenever either changes.
 
 Every drop — whether reordering within a column (`moved`) or dragging in from
 another column or the sidebar's inbox (`added`) — calls