adom-vscode

@@ -38,10 +38,12 @@ adom-vscode apikey set <value>   `/var/run/adom` if needed, mode 644, trailing newline normalized. Use it when   the frontend completes a login refresh and needs the container to pick up the   new session key.-- Typical flow with the queue: watcher sees the key aging, pushes a-  `login/refresh-needed` event (see **adom-vscode-queue**); frontend refreshes-  the session and calls `apikey set`; watcher confirms via `apikey status`-  (fresh mtime + new fingerprint).+- Typical flow with the queue (adom-vscode ships NO built-in watcher; the+  polling process and its cadence belong to HD or another owner): that process+  sees the key aging, pushes a `login/refresh-needed` event (see+  **adom-vscode-queue**); frontend refreshes the session and calls `apikey+  set`; the process confirms via `apikey status` (fresh mtime + new+  fingerprint).  HTTP: `GET /apikey`, `POST /apikey {value}`. 

@@ -34,8 +34,10 @@ Each item: `{id, ts, topic, type, payload, ttlSec}`. Default topic is  ## Patterns -- **Login refresh**: a container process notices the session key in-  `/var/run/adom/api-key` expires within a day, pushes+- **Login refresh**: NOTE, adom-vscode ships NO built-in key watcher; this is+  the pattern for whichever process owns key freshness (an HD daemon, a cron+  job, any container process). That process decides its own cadence, notices+  the session key in `/var/run/adom/api-key` is close to expiry, and pushes   `topic: login, type: refresh-needed`; the frontend pulls, shows the "needs a   login refresh" banner, refreshes, then injects the new key (see   **adom-vscode-container** for `apikey set`).