fix(web): keep mobile navigation in view

[Hmbown]

Summary

• apply the existing compact homepage navigation sizing to every public route below 520px
• cap the locale selector at 8rem and allow the action group to shrink
• pin the mobile-fit contract in the shared visual token test

Impact

At a 390px viewport, the install/docs header previously placed the menu button at x=373..409, 35px beyond the 374px content edge. The same header now ends exactly at x=374 with no document overflow, and the menu remains keyboard-labelled and interactive.

Verification

• measured 390px before/after geometry in the in-app browser
• opened and closed the mobile menu; locale, navigation, and install actions remained available
• npm run prebuild
• npm run check:facts
• npm run check:docs
• npm test (224 passed)
• npm run lint
• npm run build (260 static pages)

No-Issue: focused responsive-layout defect found during the v0.9.2 maintainer visual audit; it does not close the broader site-maturity epic #3413.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[claude]

Claude finished @Hmbown's task in 1m 35s —— View job

---

Review: PR #4947 — keep mobile navigation in view

• Gather context (diff, PR description, comments)
• Read changed files (web/app/globals.css, web/lib/blue-stage-contract.test.ts)
• Trace .site-nav-actions/.site-nav-inner usage across nav.tsx, mobile-menu.tsx, locale-switcher.tsx
• Check for regressions vs. product-home dark-theme overrides
• Check CI status
• Post final review

Scope: This is a two-file, frontend-only CSS fix (no Rust workspace / provider / model / routing code touched), so the EPIC #2608 provider-selection invariant doesn't apply here.

What the diff does: web/app/globals.css:1794-1807 de-scopes the @media (max-width: 520px) rules for .site-nav-inner / .site-nav-actions / .site-nav-actions select from body:has(.product-home) ... to bare selectors, and adds min-width: 0 to .site-nav-actions. Since Nav (web/components/nav.tsx:48-70) is the single shared header rendered on every route, this correctly generalizes a fix that was previously only active on the homepage. The min-width: 0 addition is the actual bug fix — without it, a flex child (.site-nav-actions) can't shrink below its content's intrinsic width, which is exactly what pushed the mobile-menu button past the viewport edge on non-homepage routes.

Verified no regression: the product-home dark-theme overrides at globals.css:1234-1251 (body:has(.product-home) .site-nav-actions button/select { color, border-color }) are untouched and don't overlap with the spacing/width properties this PR changes, so homepage styling is unaffected.

Test: The new blue-stage-contract.test.ts case (lines 48-57) is well-scoped — it splits on the single @media (max-width: 520px) occurrence in the file (confirmed only one exists), asserts the three de-scoped rules by name, and asserts the old body:has(.product-home) .site-nav-actions select scoped selector is gone from that block. Regexes are unambiguous (the .site-nav-actions select pattern can't false-match the parent .site-nav-actions block). This locks in the fix as a regression test, per the repo's "pin the contract" pattern used elsewhere in this file.

Reuse/simplification: No duplication introduced; the change removes a redundant scoping qualifier rather than adding one. Good — reduces surface area.

CI: Web Frontend checks have already passed (contribution gate, DCO, and Web Frontend all green); CI and this Claude review workflow were still in progress at time of review.

No correctness bugs, no test gaps, nothing to flag. Small, well-targeted fix — looks good to merge.