[ryanbr]

Draft — this is a layout change I cannot see. It compiles and the suite is green, but somebody has to look
at it on a phone before it should land.

Raised on #1836.

The bar was never the problem

GlassBottomBar is already built to float: pill shape, 22 dp inset, navigationBarsPadding(), hairline
rim, 0.80 alpha, soft shadow. It rendered as a dark strip regardless — because of where it was mounted,
not how it was styled.

It sat in Scaffold(bottomBar = …), a slot outside the screen content. Each screen paints its own
backdrop via LiquidScreenSky / BackgroundImageBackdrop, so that backdrop stopped where the bar began,
and behind the glass there was only containerColor = Palette.surfaceBase.

Translucency over a flat colour is a slightly different flat colour. With a custom background (#1234) it
reads as a block cut out of the image, which is what the side-by-side screenshots show.

What changed

The bar is drawn as a sibling over the Scaffold, so it floats on whatever the current screen painted.
Same composable, same insets — only its parent moved. The slot stays but empty, so the Scaffold reserves
nothing, and the inset it used to contribute is applied to the NavHost. Content clears the bar exactly as
before; only what sits behind the glass differs.

Deliberately not in this change

• Content scrolling under the glass. That needs every scrollable to add the bar height to its own
  contentPadding; no shared modifier can do it. LocalBottomBarHeight is exposed for that work, screen
  by screen, with a device to look at.
• The active-tab pill. BarSlot changes only colour and weight, where the system iOS bar draws a
  filled rounded background behind the selected item. That is the other visible gap and belongs in its own
  change.
• Real backdrop blur. Compose has no cheap way to sample what is behind a composable, so this is not
  blur parity — it is making the translucency that already exists show something.

Why iOS looks native

Because it is. RootTabView uses SwiftUI's TabView, so iOS 26 supplies the Liquid Glass bar, the
selected-item pill, real blur and scroll behaviour for free. Android's bar is hand-built and always will
be an approximation; this closes the part of the gap that was a mounting mistake rather than a platform
limit.

On #90

#90 is an open prototype (July) for a scroll-reactive version of this same bar, editing the same
composable and two months stale. Whichever lands first, the other should be rebased onto it rather than
both restructuring GlassBottomBar in parallel. Notes on that PR separately.

Verification

• compileFullDebugKotlin clean; full Android suite 5089 tests, 0 failures; doc-comment gate clean.
• Not seen on a device. The specific risks are the bar overlapping content on a screen whose scrollable
  does not honour the NavHost inset, and the overlay's behaviour with the keyboard open.

Now behind a setting, default off

Settings → Appearance → Bottom bar overlay, default off. Merging changes nothing on screen until
someone turns it on.

The off-path resolves to exactly what ships today — the slot renders the bar, the NavHost pads by inner,
and the overlay composable is never composed, so its measurement never runs. What changes unconditionally
is structural only: run { } became a Box, two remembered values the off-path never reads, and the
BottomBarStyleStore object.

That is the right shape for this change. Both inset bugs found while writing it were invisible without a
device, so shipping it as the only option would have been asking users to find the third one. A switch
makes it reachable for testing without a special build, while the default stays inert.

Still unverified on a device. It should be described as experimental wherever it is announced until
someone reports back from having flipped it.