fix(web): code review round 2 -- critical session/connection races

- RequireAuth: a page reload lost the session even with a valid token
  sitting in sessionStorage -- myUserId is never persisted (by design)
  but nothing ever re-derived it from the reusable login token. Added
  connection.ts's restoreSession(), which also fixes the race the first
  attempt at this ran into live: React 19 StrictMode double-invokes the
  restore effect in dev, and Tinode.loginToken() isn't idempotent (second
  call on an already-authenticated connection gets 409'd), so both the
  connect() and the login itself needed module-level in-flight dedup,
  not just a per-effect cancelled flag
- topics.ts: same dedup pattern for openConversation/closeConversation --
  StrictMode's mount->cleanup->remount always overlapped an open with
  itself, and a leave() landing before its own subscribe() resolved was
  silently no-op'ing instead of detaching
- LOGGING_ENABLED was unconditionally on, including prod builds --
  Tinode's verbose logging prints the raw login secret and full message
  content to the console
- imPost/imPatch/imPut/imDelete could silently drop the Idempotency-Key
  header for a caller that passes its own headers (object-spread order
  bug, dormant today since no call site does this yet)
- DetailColumn's getFriends()/getBlocks() only ever read page 1 despite
  fetchAllPages existing specifically to prevent this bug class
- availableActions() now defers to the server's message_policy.
  supported_actions when present instead of only a client-side time
  window, and exposes recallRemainingSeconds for the context menu's
  countdown label

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

web/src/stores/session.ts

@@ -21,9 +21,10 @@ interface SessionState {
 /**
  * Tenant context persists across browser restarts (localStorage) the same way the old app kept
  * it, since a returning user's auto-login still needs it to build the {hi} packet and every REST
- * call's X-Tenant-Code header. `myUserId` is *not* persisted here -- it's re-derived from the
- * Tinode connection's own auth state on reconnect, not something to trust stale from a previous
- * session.
+ * call's X-Tenant-Code header. `myUserId` is *not* persisted here -- trusting a stale uid from a
+ * previous session without re-authenticating would be wrong. Instead, app/RequireAuth.tsx re-derives
+ * it on mount via `Tinode.loginToken()` against the reusable session token LoginPage/RegisterPage
+ * write to `sessionStorage`, which is the actual thing that should survive a same-tab reload.
  */
 export const useSessionStore = create<SessionState>()(
   persist(