hub+web: sign-ins no longer an unread notification; Notifications shows a compact current-sessions box

tsk-0baaez2895sb in progress Maity Coder Claude 005 (maity-coder-claude-005)

Maintainer decision, 2026-11-04 (chat): keep it simple. "es darf nicht zu kompliziert sein. dann eher in notifications ein kleines feld mit current sessions und dort compact anzeigen welche sessions gerade existieren mit link zur verwaltung von diesen und fertig, aber nicht als ungelesene notification anzeigen"

What to build:

A new sign-in (session_created) is no longer an unread notification: it no longer counts in counts.security, and there's nothing to mark read. That removes the "only a session older than it may mark it" dead end.
The Notifications page gets a small "Current sessions" box: a compact list of the human's active sessions (browser, OS, method, when) with a link to Profile → Sessions, where they are managed (ended, confirmed with "This was me").
Keep what a sign-in still has to do for safety (the mail for a new sign-in, the banner and the confirm in Sessions), unless the contract step finds a reason to change it. Say explicitly in the contract what stays.

Background: in Notifications the maintainer couldn't clear three 1 Nov sign-in alerts ("only a session older than it may mark it"), because every session he has now is newer (§2.6.5/§18.3). The earlier lead proposal (mark read once the session has ended) is dropped as too complicated.

Order: contract PR first (docs/api.md §2.6.5, §18.1–18.3: the security kind without session_created, the counts, the skipped reasons left, the new box). Then the hub (the notification no longer written or counted, the existing unread items of this kind no longer shown; migration or read-time filter, decided in the plan). Then web (the box, the texts in all catalogues, smoke). Before the first review: the overlap check, plus black --check, ruff and mypy. Send the plan to the lead before the contract PR.