fix(app): inset iOS PWA navigation below native chrome

[Hona]

Issue for this PR

Closes #36142. Related: #35480.

Type of change

• Bug fix

What does this PR do?

Keep viewport-fit=cover and black-translucent, with device safe-area padding around the shell. Add left/right insets for landscape and 32 CSS pixels of extra top clearance only when the web app runs in iOS standalone mode (navigator.standalone). This moves navigation away from the reported native status-bar blur without changing normal browser or Android PWA spacing.

This replaces the earlier status-bar-meta-only workaround. The device insets follow WebKit's safe-area guidance; the extra 32px is an app-level clearance allowance, not an Apple-defined inset. The existing standalone height workaround remains unchanged.

How did you verify your code works?

• App bun typecheck and bun run build passed.
• Eight Chromium geometry/tap cases passed against both development and production builds: browser, desktop, Android PWA, iOS portrait, Dynamic Island insets, zero insets, bottom navigation, and RTL landscape. Tests use emulated safe-area values and verify all four paddings, navigation bounds, New session, the editable composer, and return to Home.
• The revised WebKit run was interrupted by a host server restart; it is not counted as a completed pass.
• E2E typecheck is blocked by an existing HTMLElement | SVGElement .dir error in new-session-workspace-pending.spec.ts:38.

Draft pending an affected iPhone check. Automation cannot validate the native fade's extent or OS-level touch interception. Verify cold launch, top-navigation taps, rotation, keyboard dismissal, and bottom navigation on the affected device with the updated build active.

Screenshots / recordings

Same 390x844 viewport with emulated 47px top / 34px bottom insets. These show the layout change; native iOS chrome is not rendered.

Before:

After:

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR