T1.4 - F4: the comments drawer opens below the header, not under it

Containing block first, as the task asks. The drawer is a body child with no
transformed ancestor, so its containing block was already the viewport - the
positioning context was never wrong. What was wrong was `top: 0` with
`height: 100vh`: the drawer started at the very top of the viewport, and the
creator's .header is sticky with z-index:100 against the drawer's 61. The
header won, so the drawer's own head - its title and its close button - was
roofed over and unreachable. It read as "off-screen" because the part you
needed was covered, not because the box had escaped the viewport.

That is why raising z-index would have been the wrong move: it does not remove
the collision, it just swaps which element is on top, and then the drawer
covers the header instead. The fix is to stop them occupying the same band.
The drawer now starts at var(--rail-top) and is that much shorter. --rail-top
is the header's measured height, set by wp-creation-app.js:1328 and already
used by .wp-nav for exactly this purpose, so "below the header" has one
definition on this page rather than two.

The iframe boundary is NOT implicated. position:fixed inside the embedded
creator resolves against the iframe's own viewport, which is self-consistent,
and the drawer behaves identically framed and unframed. T7.1 can dissolve the
boundary without revisiting this.

The probe was checking one width, one mode, and placement only. It now checks
390 and 1440, standalone and embedded, that the close button is genuinely
hit-testable via elementFromPoint rather than merely present, that the drawer
reopens after closing, and that opening it does not move the page's scroll
position. All pass.

One honest caveat, attributed rather than hidden. At 390px the drawer sits at
the right edge of a 485px layout viewport while the screen is 390px, so 95px of
it is off-screen. That is not the drawer: the creator forces its containing
block to 485px, and while chasing it I found BL-001's root cause -
wp-creation-app.js:1389 injects `body{--nav-w:288px}` with no media query,
which lands after wp-creation-styles.css:815's
`@media (max-width:860px){body{--nav-w:56px}}` and overrides it, so the page
reserves 288px of rail that is not there at any width. Every `right: 0` fixed
element on the page is displaced by it, not only this one.

Left unfixed on purpose - it is the creator's layout, T7.1 rebuilds it, and
CLAUDE.md is explicit about not fixing things noticed in passing. BL-001 now
carries the exact cause and the five rules that consume the token, so T7.1 does
not have to find it again. The probe reports it as an attributed note naming
BL-001, so nobody is sent to the wrong file.

browser_check 71/71. f_items: F1, F2, F3, F4 FIXED.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/waves/backlog.md

@@ -67,6 +67,23 @@ deliberately deferred.
   rebuilds its layout regardless — fixing it in wave 1 would be thrown away.
 - **Suggested wave or follow-up:** verify it is gone at `T7.1`; if it survives the rebuild,
   it needs its own item in the next revision.
+- **Root cause, found at T1.4 — not fixed, T7.1 owns it.** `wp-creation-styles.css:815` has
+  `@media (max-width: 860px) { body { --nav-w: 56px; } }`, which is correct. But
+  `wp-creation-app.js:1389` injects `body{--nav-w:288px;}` into a runtime `<style>` with no
+  media query. Injected last, same specificity, so it **wins over the media query** and
+  `--nav-w` stays 288px at every width. Everything keyed off it then reserves 288px of
+  rail that is not there: `.main` padding-left `calc(288px + 28px)`
+  (`wp-creation-styles.css:109`), `.ctx-bar` (`:452`), `.release-banner` (`:488`),
+  `.section-nav-bar` (`:596`) and `.sticky-save { left: var(--nav-w,288px) }` (`:820`).
+  At a 390px screen that forces the initial containing block to 485px.
+  The fix is to give the injected rule the same breakpoint, or to stop injecting the
+  value that the stylesheet already declares — one line, but it belongs with the creator
+  rebuild rather than in a wave 1 rendering task.
+- **Consequence for `F4`:** every `position: fixed; right: 0` element on this page sits at
+  the right edge of that 485px box, which is 95px off the visible 390px screen. The
+  comments drawer is placed correctly relative to its containing block; the containing
+  block is wrong. `T1.4` reports this as an attributed note rather than a drawer defect,
+  so nobody is sent to the wrong file.
 - **Update, T1.2:** the 1440px half of this is **resolved as a side effect**, not by intent.
   The unbreakable `#wp-usermenu` run that `T1.2` fixed was the cause of four of the five
   overflows recorded in wave 0 — launcher, SOP wizard and field view at 390px, and the