feat(ui): add PWA standalone reload button and pull-to-refresh gesture

[espokaos-ops]

When the WebUI is installed as a PWA (home-screen shortcut) on Android, there is no browser address bar or reload button. The only way to refresh the page is to close and reopen the app.

This PR adds two ways to reload from a PWA standalone context:

Reload button — A small refresh icon in the app titlebar, next to the message count. Only visible in display-mode: standalone or fullscreen. Tapping it triggers window.location.reload().

Pull-to-refresh gesture — Dragging down from the top of the message list shows a visual indicator (Pull to refresh / Release to refresh) and reloads on release past an 80px threshold. When triggered mid-conversation (not at the top), the message list smooth-scrolls to the top first so the user does not have to manually scroll up in long sessions.

Both features are gated behind a matchMedia check and have no effect in normal browser mode.

Changes

• static/index.html — Reload button in the app titlebar
• static/style.css — Button styles + pull indicator, scoped to standalone/fullscreen
• static/ui.js — Touch gesture handler with scroll-to-top fallback

[nesquena-hermes]

Phase 0 fit + UX gate — agent-review queued, applying ux label

Thanks @espokaos-ops — narrow PWA quality-of-life improvement, the kind of thing PWA users have been asking for. Two notes before this can route to a batch:

UX gate: this adds two new visible UI affordances — a titlebar reload button (#btnReload next to message count) and a pull-to-refresh indicator that appears on touchstart at scrollTop=0. Both are gated behind (display-mode: standalone), (display-mode: fullscreen) so they're invisible to browser users, which is the right shape. But:

1. The pull-to-refresh indicator overlays the messages container with position: absolute; top: 0. On long transcripts a user can accidentally trigger it while scrolling up to read history — please confirm via screenshot/video that the 80px threshold + smooth-scroll-to-top guard makes this feel intentional rather than surprising.
2. The reload button styling — please show how it renders in both light and dark themes at the standard breakpoints (390/1280/1440/1920). The var(--muted) → var(--text) hover transition needs to look right alongside the existing titlebar dot/count.

Applying the ux label for the next UX review tick.

Agent review queue: the codebase pattern for new visible UI surfaces is to land an agent-review pass first (per-file diff/test/integration read with a recap comment). Will let that cron pick it up on the next tick before this routes into a batch.

The diagnosis — that PWA standalone has no browser-level reload affordance — is real and worth solving. Just want to make sure the surface lands clean before it ships.

[espokaos-ops]

4-Viewport Gate Evidence ✅

Screenshots uploaded to screenshots-pr2548/ covering all requested combinations:

Reload Button

390px (mobile): light · light:hover · dark · dark:hover
1280px: light · light:hover · dark · dark:hover
1440px: light · light:hover · dark · dark:hover
1920px: light · light:hover · dark · dark:hover

Pull-to-Refresh Active

390px: light · dark
1280px: light · dark
1440px: light · dark
1920px: light · dark

Full page idle (dark, 390px)

fullpage_idle_dark_390.png

Notes

• The var(--muted) to var(--text) hover transition reads cleanly across all breakpoints, no contrast issues in either theme
• The PTR indicator uses position absolute top 0 within messages-shell, clean overlay at every width
• 80px threshold + scrollTop guard prevents accidental triggers on long transcripts: the guard at touchstart exits immediately if scrolled down, scrollTo smooth on touchmove gives natural feel near the top

[nesquena-hermes]

UX gate review on viewport evidence — clears the 4-viewport bar; one concrete code-level concern

Read the PR head (a5a0de2a) end to end after the screenshot uploads, focusing on static/index.html:138-148, static/style.css:425-442, and static/ui.js:1914-1978. The screenshots address the visual gate, but one behavioral concern still merits a small follow-up.

What the screenshots confirm

The reload button at all 4 widths × 2 themes × hover/idle renders cleanly. The var(--muted) → var(--text) hover transition is consistent against the existing titlebar treatment, no contrast inversion in either theme. The PTR indicator overlay (position:absolute;top:0; within #messages) sits correctly above the message stream and doesn't clip the existing date separator (.msg-date-sep) or sticky scroll affordances.

One behavioral concern that screenshots can't capture

Reading the touchmove handler at static/ui.js:1947-1963:

el.addEventListener('touchmove',function(e){
  if(_ptrState!==1) return;
  _ptrCurrentY=e.touches[0].clientY;
  const pull=_ptrCurrentY-_ptrStartY;
  if(pull<0){ _ptrReset(); return; }
  /* If not at the top, smooth-scroll to top first.
     Next pull gesture will trigger the refresh. */
  if(el.scrollTop>0){
    el.scrollTo({top:0,behavior:'smooth'});
    _ptrReset();
    return;
  }
  const progress=Math.min(pull/THRESHOLD,1);
  _ptrUpdate(progress);
  _ptrState=progress>=1?2:1;
  if(progress>0.3) e.preventDefault();
},{passive:false});

The touchstart guard at :1942 is el.scrollTop>0||_ptrState!==0 → return — so a touch that begins mid-scroll exits early. Good. But once _ptrState=1 is set at scrollTop=0, a user reading a long transcript can scroll up, hit the top, then continue the same swipe gesture, which then triggers progress increment with pull>0 and e.preventDefault() from progress>0.3. That feels surprising on long-form reading: the scroll abruptly stops accumulating thinking-card detail and converts to a refresh prompt.

Two ways to make this feel intentional rather than accidental:

1. Velocity guard: track the time delta on touchstart and only enter _ptrState=1 if the gesture is "starting fresh" — e.g. require the previous touch sequence to have ended at least ~150ms ago. The current code has no idle gap, so a continuous swipe from mid-transcript to the top can carry into PTR territory without the user committing to it.

2. Distance guard: require a clear "rest at scrollTop=0" frame before allowing pull accumulation. Something like:

   if(el.scrollTop>0){
     el.scrollTo({top:0,behavior:'smooth'});
     _ptrReset();
     return;  // already does this — but consider holding state=0 here too
   }

   Already the right idea, but _ptrState was set to 1 in the earlier touchstart, so the touch can still pull. Hoisting the "snap to top first" check into touchstart (so _ptrState=1 only sets if el.scrollTop===0 at start, not at the time touchmove fires) would close this.

Both are 5-line tweaks. Neither blocks the PR if the PWA pool is mostly people who restart from a fresh open, but it's worth a paragraph in the PR body explaining the chosen tradeoff for the next reviewer.

Other things that look fine

• aria-label="Reload" + title="Reload page" on the button matches the existing .app-titlebar-* icon-only pattern.
• The @media (display-mode: standalone), (display-mode: fullscreen) gate at static/style.css:425-442 is correctly duplicated against the existing --app-titlebar-safe-top block — the merge looks clean.
• The IIFE wrap at static/ui.js:1916 keeps _ptrState / _indicator out of global scope. The early-return on !isStandalone is the right shape for browsers — zero cost when PWA isn't active.

Lifecycle question

What happens to the PTR listeners if a user installs the PWA mid-session and matchMedia('(display-mode:standalone)') becomes true after attachLiveStream is already running? The IIFE evaluates once at script-load — so the listeners simply won't bind for that user until next page load. That's likely fine (reload-to-activate is the usual PWA install flow), but worth a single-line comment in the IIFE noting this is intentional.

Otherwise UX gate clears. I'm not seeing reasons to block. The velocity/distance behavior is the only thing worth a small follow-up commit before this routes into a batch.