Bottom bar: hide it while scrolling down, bring it back on scrolling up #1839

Ask

With the overlay bar landed (#1838), the bar sits over content. The natural next step is for it to get out
of the way while you are reading and come back when you reach for it — hidden as you scroll down, restored
as you scroll up.

Configurable, not automatic.

Only meaningful with the overlay

In the slot layout the Scaffold has reserved the bar's space. Translating the bar away there leaves an
empty band rather than handing the space back to content, which looks worse than not hiding at all. So the
setting is gated on the overlay being on, and the row greys out rather than silently doing nothing.

Prior art

#90 is a two-month-old prototype of the same idea, currently CONFLICTING and DIRTY. Three things in it
are worth keeping and are reused:

• One NestedScrollConnection on the shell, so every screen inherits the behaviour with no per-screen
  wiring — scrollable children dispatch their deltas up to it.
• The bar moves by graphicsLayer only — GPU, per frame, no relayout — so content never reflows and
  scrolling stays smooth.
• The decision lives in plain functions with their own test rather than inside composition.

It also restructured the same composable the overlay work has since rewritten, so this is a fresh
implementation of its idea rather than a rebase of its diff.

One deliberate difference: Reduce Motion

#90 snapped the bar between hidden and shown when Reduce Motion was on. This keeps it visible instead.
A bar that teleports away with no animation reads as a glitch, and someone who has asked for less motion is
the last person who should be handed one. Pinned by a test.

Not doing

• A partial recede (shrink + fade, staying reachable) — PROTOTYPE: scroll-reactive bottom bar (Instagram-style) (#86) #90's original feel. It is a tuning question
  best answered by looking at both on a device, and full hide is what was asked for.
• Per-screen opt-outs. One connection on the shell means uniform behaviour; a screen that wants
  different behaviour is a reason to revisit, not to fragment it up front.