Profile page shows horizontal scroll on mobile

[serge-ivo]

Problem

On mobile, /console/profile can appear horizontally scrollable. This is user-visible on the Profile page and should be treated as a mobile layout regression.

Investigation notes

• Existing regression guard includes /console/profile, but only at 375px: e2e/console.spec.ts mobile overflow block around the routes array.
• That guard checks <main> and documentElement overflow, and explicitly ignores the header nav because the nav is intentionally overflow-x-auto.
• Local ad hoc measurement at 320/360/375/390 with mocked profile data found no document-level or <main> overflow, but did find the top primary nav horizontally scrollable on Profile:
  • store/console/src/components/Layout.tsx uses overflow-x-auto on the primary nav.
  • This may be what users experience as horizontal page scroll, especially on touch devices where the header pans.
• Profile also has several tight single-row flex layouts that should be hardened for narrower phones and real data:
  • API token row: store/console/src/pages/Profile.tsx around the API Token section uses one flex row with a token span plus Copy/Show buttons.
  • Account rows use truncation and max widths; real IDs/tokens/logins should be tested at 320px and 360px.

Suggested fix

• Reproduce on a real mobile viewport/device, especially 320px wide and iOS Safari if possible.
• Decide whether the primary nav should be horizontally pannable on mobile Profile, or collapse/hide behind the hamburger so the page does not feel horizontally scrollable.
• Harden Profile rows with wrapping/min-width constraints as needed, especially API Token:
  • allow flex-wrap on the token action row, or stack buttons below the token on small screens
  • add min-w-0 to shrinkable flex children where missing
  • keep long token/user/provider strings clipped or wrapped without widening the row
• Extend the E2E guard to cover 320px and to detect unintended horizontal scrollable descendants outside known allowlisted strips.

Acceptance criteria

• /console/profile has no document-level or <main> horizontal overflow at 320px, 360px, and 375px.
• Header/nav behavior on mobile is explicit: either intentionally scrollable and documented/allowlisted, or replaced by a non-panning mobile control.
• Long token, long user id/login, and API provider rows do not create horizontal scroll.

[serge-ivo]

Fixed in 0a7a3b4.

Verified state: partly true — and the investigation notes were right where the title was not. Measured at 320/360/375 with real-shaped data: /console/profile has no document-level or <main> overflow, before or after this change. What pans is the primary nav — 25px at 375, 80px at 320 — on every route that shows it, not just Profile. On a touch device that IS what 'the page scrolls horizontally' feels like, and the existing guard explicitly excused it as an intentional overflow-x-auto strip. So the guard was green on the page users were complaining about, and it was green for a second reason: the fixture.

Why the guard missed it (the gap):

1. It allowlisted the one element that actually pans.
2. It ran Profile with user-1 / tester, no profile fields, no API providers, and a 15-char token — so three of the page's five sections never rendered. It was measuring a page users never see.
3. It only ran at 375px.

Shipped:

• Eight destinations never fit a phone header, and the hamburger beside it already lists exactly those items with labels. The strip is hidden below sm instead of pannable; from sm up it fits and is untouched. That answers acceptance criterion 2 by making the behaviour explicit rather than allowlisted.
• Guard now asserts the primary nav does not pan (proven non-vacuous: reverting the fix fails it by 163px), sweeps every route at 320px as well as 375px, and flags any unexpected horizontally-scrollable element inside <main>.
• New Profile block at 320/360/375 with a real-shaped account (uuid id, long login, seven profile fields, four providers) and the token revealed, asserting each section actually rendered first.
• Row hardening per the ticket: the API-token row wraps and its span can genuinely shrink (min-w-0 — without it a flex child will not go below its content width), and provider names truncate.

64 e2e passing.