fix(desktop): paint full-height community rail to close traffic-light gaps

[bradhallett]

Problem

Since v0.5.0 (#2972), differently-colored blocks appear above and below the community rail in every dark theme. The rail paints --sidebar, but the surrounding blocks show --background.

Root cause

#2972 moved the macOS traffic-light clearance from padding inside the painted <nav> to margins outside it. CSS margins are transparent, so the parent's --background shows through beside the --sidebar-painted rail:

• Top: ~56 × 41 CSS px (traffic-light band)
• Bottom: ~56 × 8 CSS px (mb-2)

At Retina 2× these are ~112 × 82 and ~112 × 16 physical px — large enough to read as distinct color blocks in every dark theme, where --background and --sidebar are perceptually distinct.

Fix

Wrap the rail in a full-height bg-sidebar surface that owns the width, z-index, and flex column. The inner <nav> retains its mt/mb, so the intended geometry (rail-to-content alignment, traffic-light clearance, bottom spacing) is unchanged — only paint ownership moves to the wrapper.

This preserves the alignment improvements from #2972 rather than reverting them.

Test

Extends the existing "clears the macOS traffic lights" E2E test to run under a dark theme (dracula) and assert via elementFromPoint that the surface owns the paint in both the top and bottom gaps — not just geometry alignment.

Verification

• just ci — full gate green (fmt, clippy, all unit tests, desktop build, Tauri check, web build, 862 mobile tests)
• Community-rail E2E suite — 19/19 passed (dark theme)

[bradhallett]

Closing as superseded by #3382 (fix(desktop): paint community rail full height), which landed on main and resolves the same community-rail traffic-light gap with a cleaner approach — converting the clearance from mt margin (transparent, --background bleed) to pt padding so the single <nav> owns the full-height bg-sidebar paint. No reason to carry a competing wrapper-div approach. Conflict resolution would just duplicate an already-shipped fix.