Atlas HUD hides behind the navbar once scrolled (the type chip is unreachable) — h-screen overflows by 297px

[TortoiseWolfe]

The HUD's top hides behind the navbar — intermittently

Reported by the owner with an annotated screenshot: the atlas HUD's title, its 8031 buildings · … line, and the entire [source][type][height] chip row sit behind the sticky navbar. The type chip is unreachable — you cannot switch the legend to building types at all.

Owner also: "The HUD claims too many pixels as it is."

"It renders fine now but randomly glitches later"

It isn't random — it's scroll position. Measured live on prod:

scrollHeight  927        navHeight  65   (sticky top-0, z-50)
innerHeight   630        panelTop   77   (absolute top-0, z-10)
overflowPx   297   <- the page scrolls

src/twin/cesium/AtlasViewer.client.tsx:613 is relative h-screen (100vh), but it sits below the 65px sticky nav, inside a document that also renders a ~232px footer:

65 + 630 + 232 = 927, against a 630 viewport → 297px of scroll.

At scroll 0 the panel clears the nav by 12px and everything looks perfect. Scroll at all and the container slides up while the sticky nav stays — and the panel is z-10 against the nav's z-50, so the nav wins and eats the HUD's top. That scroll-dependence is the entire "glitches later". (It's also why the maintainer's screenshots looked fine and the owner's didn't: nobody had scrolled.)

100vh is itself unstable on mobile — browser chrome hiding/showing re-lays-out the page — so 100dvh matters and may be a second glitch source.

Repro

1. Open /chatt/.
2. Scroll down even slightly.
3. The title, buildings line and chip row disappear under the navbar.

One root cause, two symptoms — the backlog only recorded one

AtlasViewer.client.tsx:719-720 already names half of it:

"This container is relative h-screen but sits BELOW the ~65px nav, so it is 100vh tall starting at y=65: its bottom edge is ~65px past…"

…but only ever framed as the globe's bottom being clipped. #292's backlog inherited that framing. The HUD's top being eaten is the same h-screen overflow seen from the other end.

Also colliding

The top-right target card (:816, absolute top-3 right-3 z-10) overlaps the nav's PWA-install button — same z-10-vs-z-50 fight. Visible in the owner's screenshot.

PR #297 made it worse — that's on us

The tour-discoverability fix turned ▶ tour from a chip sharing a row with ⊹ corners into a full-width button on its own row, with corners dropped below: ~46px taller. That's the direct cause of "claims too many pixels as it is."

Fix directions — for this issue to decide, not decided here

1. Full-bleed: container 100dvh - nav, footer suppressed on the twin route → page height == viewport → cannot scroll → the HUD can never hide. Also un-clips the globe's bottom (Chattanooga atlas (Cesium) — remaining Build Plan phases #292). Biggest change; a footer under a full-screen map was arguably never useful.
2. Pin the HUD below the nav (sticky/offset) → keeps footer and scroll, fixes only the hiding, leaves the globe clipped.
3. Shrink the HUD regardless of the above: Play + corners back on one row (still 44px, still primary), collapsible legend. Addresses the pixel complaint independently. See also the duplicate-card issue — three overlays is two too many for one map.

This is a class, not a one-off

Second sighting of full-screen canvas route vs sticky nav: #299 is the diorama's "Chattanooga Mini" wordmark behind the same nav, with toBeVisible() passing on it for months because it checks CSS and not occlusion. Worth solving as a pattern.

Deferred, but record it here

AtlasViewer.client.tsx:87 and :96 both hard-code 'provenance' (the chip labelled source) as the colour-by default. The owner asked to default to type — the middle chip. It's moot while the chip is unreachable, so it belongs with this fix. Two notes for whoever does it: both sites must change together or the legend and geometry disagree on first paint (the ref exists so the main effect doesn't take colorBy as a dependency); and 72% (5769/8031) of buildings are untyped in OSM (building=yes), so the type view is mostly one flat bucket — which may be exactly the point, since it exposes how thin OSM's type coverage is.

Refs #292, #299.