fix(web): the session inventory lists only the keys the chat can open

The sidebar grouped everything that was not `interactive:` under
"other keys", minus the phone's status keys. That included the coding
jobs' `job:<instance>#<id>` keys and forge keys — and those are dead
ends: the message, event and history routes answer only for the
resident prefixes (`is_resident_key`), so opening one 400s and the row
sits there looking busy with nothing inside. A finished job's key was
worse than useless while its dispatch spun: `reacquire`, forever.

`isResidentKey` names the rule once, beside `isInteractive` —
`interactive:`, `task:`, `calendar:` — and the inventory filters on it.
That leaves the phone's keys out as before, keeps scheduled tasks
(their turns have real transcripts), and stops offering keys the chat
surface cannot address. The shell's `nextActiveKey` follows the same
rule: after a delete the chat moves to the next key it can open, or to
none. The full list stays on the wire — the API's inventory is the
dispatcher's, not the client's, and the delete route still answers for
any key with a record.

Consequence worth naming: a `job:` or forge key has no row now, so it
cannot be deleted from the sidebar either.

web/claw/README.md

@@ -119,9 +119,11 @@ Two consequences worth knowing before changing this code:
 - **Sessions are created in place.** The sidebar's `+` form posts
   `POST /v1/sessions` with a client-validated name
   (`[A-Za-z0-9._-]{1,64}`), switches the chat to the new key, and
-  lets 400/409 land in the error banner. The phone client's status
-  keys (`phone:…`) stay out of the inventory; the full list stays on
-  the wire.
+  lets 400/409 land in the error banner. The inventory lists only the
+  resident prefixes (`interactive:`, `task:`, `calendar:`) — the ones the
+  message, event and history routes answer for. The phone's status keys
+  (`phone:…`), the coding jobs' `job:<instance>#<id>` keys and forge keys
+  stay out, and the full list stays on the wire.
 - **Deleting a session is a decision, not a click.** The row's delete
   button only names the key; the shell's dialog spells out that the
   turn history goes with it, and `DELETE /v1/sessions/{key}` runs on