Use lvh/lvmin, not svh/svmin - svh was the wrong end of the viewport

Both stable, but svh pins to the *smallest* viewport (toolbar
visible), which never grows once mobile Safari auto-collapses its
toolbar on the first scroll. The actual visible screen becomes taller
than a box sized with svh, so content below it appears to snap into
the newly-revealed space the moment the toolbar collapses - exactly
the "text jumps down with the expanded area" behavior reported.

lvh pins to the toolbar-collapsed size instead, matching the settled
state scrolling actually lands on, so there's no gap to reveal. svh
is the right choice for the opposite case (a fixed element that must
never be hidden behind the toolbar), not a hero at the top of a
scrolling page - wrong tool for this particular job.

style/main.css

@@ -53,21 +53,25 @@
 
   --radius: 1.1rem;
 
-  /* responsive base size: scales with viewport (2.1svmin) on top of a
+  /* responsive base size: scales with viewport (2.1lvmin) on top of a
      fixed floor (3pt) so it keeps growing on large/wide screens
      instead of capping at a fixed px value like the old 17px did;
      max(12px, ...) keeps it from shrinking below legible on tiny
-     viewports. svmin (small-viewport min), not plain vmin - plain vh
+     viewports. lvmin (large-viewport min), not plain vmin or svmin -
-     -based units recalculate as mobile Safari's address bar
+     plain vh-based units recalculate as mobile Safari's address bar
      hides/shows on scroll, which would reflow every text size on the
-     page mid-scroll; svmin stays fixed to the smallest viewport state,
+     page mid-scroll. svmin would be stable too, but pinned to the
-     same stability .hero-yes gets from 100svh below.
+     *smallest* (toolbar-visible) state - wrong end for a page whose
+     toolbar collapses the moment you scroll: same mismatch as
+     .hero-yes below, just for font-size instead of height. lvmin
+     matches the settled (toolbar-collapsed) state scrolling actually
+     lands on.
      Plain-px fallback declared first: an engine that doesn't
-     understand svmin/calc() here treats the whole line as invalid and
+     understand lvmin/calc() here treats the whole line as invalid and
      ignores it, leaving this in effect instead of falling through to
      the UA default. */
   font-size: 17px;
-  font-size: max(12px, calc(2.1svmin + 3pt));
+  font-size: max(12px, calc(2.1lvmin + 3pt));
 }
 
 * { box-sizing: border-box; }
@@ -149,13 +153,22 @@ main.loading, main.not-found {
   position: relative;
   max-width: none;
   width: 100%;
-  /* plain-vh fallback first - same reasoning as :root's font-size
+  /* lvh (large viewport height), not svh: svh pins to the *smallest*
-     above: an engine without svh support ignores the invalid second
+     viewport (toolbar visible), which never grows once the browser
-     line rather than falling through to auto height, which would
+     auto-collapses its toolbar on the first scroll - so the actual
-     collapse this to the height of its in-flow content and clip the
+     visible screen becomes taller than this box, and the content
-     canvas via overflow:hidden below. */
+     below appears to snap into the newly-revealed space the moment
+     that happens. lvh pins to the toolbar-collapsed size instead,
+     matching the settled state scrolling actually lands on, so
+     there's no gap to reveal. (svh is the right choice for the
+     opposite case - a fixed element that must never be hidden behind
+     the toolbar - not a hero at the top of a scrolling page.)
+     Plain-vh fallback declared first - an engine without lvh support
+     ignores the invalid second line rather than falling through to
+     auto height, which would collapse this to the height of its
+     in-flow content and clip the canvas via overflow:hidden below. */
   height: 100vh;
-  height: 100svh;
+  height: 100lvh;
   padding: 0;
   justify-content: flex-end;
   overflow: hidden;