aws-sso: renew just after the browser sign-in ends, not before; auto-continue

AWS: CLI sessions refresh only while the user interactive session (browser
sign-in) is valid; a login inside it is silent but inherits its end (green
box 'can be used until your session expires', 2026-10-11). Renewing early
gains nothing, so renew 2 min after the estimated end, forcing a fresh IdP
sign-in while the last 1-hour token still works. Silent renewals keep the
anchor. On an expired-session request failure, renew then send 'continue'
(once per 10 min). New: /aws-sso continue on|off, signed-in HH:MM.

README.md

@@ -370,21 +370,33 @@ Off until you enable it.
 | `/aws-sso now` | Log in now |
 | `/aws-sso mode mac` | Run `aws sso login` on the Docker host over SSH (`~/.ssh-local/config`, host alias `host` or `$PI_AWS_SSO_SSH_HOST`): your own browser opens. Default when the sidecar config exists. |
 | `/aws-sso mode device` | Run `aws sso login --use-device-code --no-browser` here and show link + code in pi; approve on any device. For SSH/tmux sessions. |
+| `/aws-sso continue on\|off` | After a request failed on an expired session and the renewal succeeded, send `continue` (default on) |
+| `/aws-sso signed-in HH:MM` | Correct the estimated start of the browser's sign-in |
 | `/aws-sso hours <n>` | Session length if your IdC admin changed it (default 8 h, measured) |
 
 `PI_AWS_SSO_REFRESH=1` / `=0` force it on / off regardless of the saved state.
 
-**How it knows when the session ends.** The AWS SDK already refreshes the 1-hour
-access token inside a session; only the session itself expires (admin-set; 8 h
-measured on 2026-10-10). Its start is not stored anywhere, so the extension
-treats a new *refresh token* in `~/.aws/sso/cache/<sha1(sso-session)>.json` as a
-new session and remembers when it first saw it. Tokens are only ever logged as
-`sha256[:8]` fingerprints (`~/.pi/agent/aws-sso/events.jsonl`).
+**When it renews — and why not earlier.** Per AWS ("Understanding authentication
+sessions"), the CLI's 1-hour token is refreshed by the SDK "as long as the underlying
+user interactive session remains valid" — that is the browser's AWS sign-in,
+admin-capped (8 h measured 2026-10-10). A login while it is valid completes
+silently ("…can be used until your session expires") but **inherits its end**, so
+renewing early gains nothing. The keeper therefore renews **2 minutes after** the
+estimated end: the browser must sign in again through the IdP (silent while
+"stay signed in" holds) and a fresh session starts, while the CLI's last 1-hour
+token still covers the gap. If a request fails on an expired token anyway, it
+renews and sends `continue` (once per 10 min; `/aws-sso continue off` to disable).
 
-**Triggers:** a 60 s timer (20 min before the end; one attempt per session, so an
-ignored login does not loop), `before_agent_start` (if the session has already
-expired, log in and wait before sending the prompt), and `message_end` (a request
-failed with an expired-token error → log in, then tell you to send `continue`).
+The session start is not stored anywhere. The keeper watches the refresh token in
+`~/.aws/sso/cache/<sha1(sso-session)>.json`: a new one **after** the end (or after
+an observed expiry) starts a new session; a new one **before** the end is a silent
+renewal and keeps the old end. `/aws-sso signed-in HH:MM` corrects the estimate.
+Tokens are only ever logged as `sha256[:8]` fingerprints (`~/.pi/agent/aws-sso/events.jsonl`).
+
+**Triggers:** a 60 s timer (2 min after the estimated end; one attempt per session,
+so an ignored login does not loop), `before_agent_start` (session already expired →
+log in and wait before sending the prompt), and `message_end` (a request failed
+with an expired-token error → log in, then send `continue`).
 Only interactive sessions act; print/JSON children (`task`, `fork`) stay inert.
 A lock file stops several pi processes from starting several logins.