feat(web): add fullscreen preview for shared turns

[techotaku39]

Summary\n\n- Add a full-viewport mode to the share-as-image dialog while keeping conversation content selectable and copyable.\n- Remember the fullscreen preference across share dialog openings with browser local storage.\n- Keep fullscreen preview state independent from PNG export generation and resolution.\n- Preserve responsive margins and spacing across desktop, mobile, normal preview, and fullscreen preview.\n- Add localized accessible labels, fullscreen icons, and regression coverage for preview geometry and export behavior.\n\n## Problem / Motivation\n\nThe share preview needs more canvas space for long conversations without turning into an image-only viewer or affecting the final exported image. The preview also needs consistent spacing across responsive layouts.\n\n## User Impact\n\nUsers can expand the entire preview dialog to the viewport, continue selecting and copying text, and reopen the share dialog with their previous fullscreen preference. Exported images retain their existing resolution behavior.\n\n## Risk / Rollback\n\n- Low risk: changes are scoped to the Web share preview dialog, icons, localization strings, styles, and related E2E coverage.\n- No database migration or new external dependency is required.\n- The change can be rolled back by reverting this change set.\n\n## Validation\n\n- �un typecheck — passed.\n- pwsh -NoProfile -File .\scripts\Invoke-HapiTaskPlaywright.ps1 -Name share-fullscreen-preview -Suite Root share-turn.spec.ts — 15 passed.\n- �un run test:web — 264 files and 2,555 tests passed.\n- �un run build — passed.\n- git diff --check — passed.\n- Local health check and the public seeded test session both returned HTTP 200.\n\n## Related Issues\n\nNone\n\n## AI Assistance\n\nImplemented and validated with OpenAI Codex (GPT-5.6).

[github-actions]

Findings

• [Major] Fullscreen ignores HAPI's mobile viewport and safe-area contract - the new dialog hard-codes 100dvh, although web/src/hooks/useViewportHeight.ts documents that 100dvh does not shrink on some mobile browsers and Telegram supplies --tg-viewport-stable-height. With viewport-fit=cover, the absolute controls also remain at raw top-2 / edge offsets, so the fullscreen close/restore controls can sit under the status bar or notch and the bottom actions can extend behind the keyboard/home indicator. Evidence: web/src/components/AssistantChat/ShareTurnDialog.tsx:757.

  Suggested fix:

  const fullscreenHeight =
      'var(--tg-viewport-stable-height, var(--app-viewport-height, 100dvh))'
  
  style={isFullScreen ? {
      left: 0,
      top: 0,
      width: '100vw',
      maxWidth: 'none',
      height: fullscreenHeight,
      maxHeight: fullscreenHeight,
      paddingTop: 'calc(1rem + env(safe-area-inset-top))',
      paddingBottom: 'calc(1rem + env(safe-area-inset-bottom))',
      paddingLeft: 'calc(1rem + env(safe-area-inset-left))',
      paddingRight: 'calc(1rem + env(safe-area-inset-right))',
      transform: 'none'
  } : undefined}
  // Apply matching safe-area top/left/right offsets to both absolute controls.

Questions

• None.

Summary

Review mode: initial

One Major finding. No other diff-attributable issues found at 80%+ confidence. Residual risk: the added mobile Playwright coverage uses a normal iPhone viewport but does not exercise HAPI's custom viewport-height variables or non-zero safe-area insets.

Testing

Not run (automation; PR code was not executed). GitHub Actions integration job failed at bun run test:cli:integration; the main test job was still pending at review time.

HAPI Bot

[github-actions]

[MAJOR] Fullscreen bypasses the mobile viewport/safe-area contract

100dvh is not the canonical app height here: useViewportHeight.ts documents that it does not shrink on some mobile browsers, while Telegram supplies --tg-viewport-stable-height. The dialog can therefore extend behind the keyboard/Telegram chrome. The absolute fullscreen and close controls also keep raw top/edge offsets under viewport-fit=cover, so they can sit beneath a notch or status bar. The new iPhone test does not set the app height variables or non-zero safe-area insets, so it misses this path.

Suggested fix:

const fullscreenHeight =
    'var(--tg-viewport-stable-height, var(--app-viewport-height, 100dvh))'

style={isFullScreen ? {
    ...,
    height: fullscreenHeight,
    maxHeight: fullscreenHeight,
    paddingTop: 'calc(1rem + env(safe-area-inset-top))',
    paddingBottom: 'calc(1rem + env(safe-area-inset-bottom))'
} : undefined}
// Offset both absolute controls with env(safe-area-inset-*), too.

[github-actions]

Findings

• None.

Questions

• None.

Summary

Review mode: follow-up after new commits

No issues found in the full latest diff at the required confidence threshold. The prior viewport/safe-area finding is addressed by the canonical app-height variable chain and safe-area offsets. Residual risk: the mobile coverage runs on Chromium with an iPhone descriptor and verifies safe-area CSS tokens, but does not exercise non-zero iOS/WebKit safe-area insets.

Testing

Not run (automation; PR code was not executed). At review time, the main test job was pending and integration had failed at bun run test:cli:integration; the failure cause was not available in the job metadata inspected.

HAPI Bot