Pin the sticky header and size panes from its measured height

[atabisz]

Three layout defects in the Observability app that compound with each other. All measured in a
browser on a clean checkout, at a root font-size of 15px — worth stating, because that makes the
assumed 3.5rem 52.5px rather than 56px, and every number below is against that.

1. The sticky header is not pinned

AppHeader is sticky top-0, but globals.css sets overflow-x: hidden on body. Any
non-visible overflow makes body a scroll container, and position: sticky resolves against
its nearest scrolling ancestor — so the header pins itself to a box that never scrolls (the
viewport scrolls, body does not) and travels off-screen with the content.

Scrolled 2136px down, the header's viewport-relative top reads -2136. Switching body to
overflow-x: clip returns it to 0, and switching back reproduces it. clip clips identically
but does not create a scroll container, which is the whole difference here. overflow-x: hidden
stays on html, where it does stop the mobile horizontal scroll it was added for.

2. Five panes assume the header is 3.5rem tall

docs, system, memory/knowledge, WikiSidebar and WikiMeta all size themselves with
h-[calc(100vh-3.5rem)]. But the header's height is not a constant: tier 1 is min-h-14 around
a flex-wrap nav that grows a row when its items wrap, tier 2 renders only inside /system, and
there is a mobile menu.

viewport width	header height	vs. 3.5rem (52.5px)
676px	53.5px	1.02x
836px	238px	4.53x
1076px	167.5px	3.19x
1713px	91px	1.73x

The nav is already on two rows at 1713px, so the assumption is off by 38.5px on a wide desktop and
by 185.5px at the worst width — each pane is that much too tall, so its bottom edge and the end of
its scroll track fall below the fold.

AppHeader now measures itself with a ResizeObserver and publishes the height as
--app-header-h; the five panes consume it. globals.css defines a first-paint fallback of
calc(3.5rem + 1px) — tier 1 at its minimum plus its bottom border, so a pane is briefly slightly
too tall rather than clipped before hydration — and every consumer repeats that same value as a
var() fallback. That repetition is not redundancy: an unresolved custom property is invalid at
computed-value time, so the whole declaration is dropped and the pane silently reverts to auto
height with nothing logged anywhere.

The open mobile menu is subtracted back out of the published height. It is a long list: measured at
1297px against an 824px viewport, so including it would publish 1351.5px and make
calc(100vh - 1351.5px) resolve to -527.5px, which CSS floors at 0. The pane collapses, and
collapsing it resets its scroll offset — so closing the menu would return you to the top of the
document. The menu is md:hidden, and at md and above it is absent from the DOM entirely, so the
subtraction is a no-op there.

3. main used min-h-screen

The header is sticky rather than overlaid, so the space left for content is the viewport minus the
header. min-h-screen made every page a full viewport tall inside a container that starts below
the header, pushing a scrollbar onto pages that fit.

Verification

8 files, +66/-7, additive on every file. In a browser, across the four widths above: the published
value equals the header's rendered height at each one, and main's computed min-height equals
the viewport minus that height at each one. With the mobile menu open on /docs the published
value stays at the collapsed header's height and the pane holds 769.5px of an 824px viewport. The
measured heights span 4.4x across those widths, so no fixed value can satisfy both the 676px and
the 836px case — which is what the current constant is trying to do.

One thing I deliberately left out: wrapping the five panes in max(0px, ...) would make the
collapse in section 2 unreachable regardless of what is published. It is a real hardening, but it
changes all five expressions to defend against a case this patch already prevents, so it seemed
better as a separate change than mixed into this one.