fix(-w): restore the window-style button icons

[adamXbot]

The complaint is real: custom/windows-swapclose.css re-positions and re-orders the window buttons but ships no icon rules, so the buttons keep the theme's WhiteSur macOS circles while the README's phrase "re-order the close button from MacOS styling to Windows" reads as a promise of Windows-looking buttons. I took option (b) — correct the docs — because option (a) is not implementable or verifiable here: on the macOS build .titlebar-close/-max/-min are display:none with 0x0 rects (the system draws the real traffic lights), and the macOS Firefox package contains no window-controls/*.svg glyph assets at all, so there is nothing to restore and no way to see it work. On Windows, restoring native glyphs would also mean reverting parts/windows.css's deliberate list-style-image: none !important on .titlebar-button, i.e. undoing the macOS look that is the whole point of the theme. The fix rewrites the README paragraph to say position-and-order-only and to state plainly that native Windows glyphs are out of scope, and adds a matching header comment to the sheet so the next reader does not re-open this.

What changed, measured

	measurement
before	On /tmp/theme-master with custom/windows-swapclose.css loaded live (Firefox 153.0.3, Darwin): the sheet does move and reorder the box — #TabsToolbar .titlebar-buttonbox-container x goes 2 -> 1193 and .titlebar-close computed order goes -1 -> 1 — but the icon never changes: computed background-imag
after	Same probe on /tmp/fix-169/patched: byte-for-byte the same numbers (box x=1193, close order=1, background-image still titlebutton-close.svg, display:none 0x0) — intended, because the fix is option (b), a documentation correction. Rendering proof of no side effects: before.png vs after.png differ in

Preview

Collateral check — full 18-view capture against master

26 views captured per side (light/dark/extra/variant, --variants all), compared with fxcss compare --platform macos: 1 of 26 changed. extra-04-audio: changed 0.141%. That view is a known capture flake, not my change — the shot-after run printed "note: audio tab is not reporting sound; capturing anyway", and the diff image shows exactly one missing element, the speaker indicator glyph on the "Now playing" tab. My change is a README paragraph plus a CSS comment, neither of which can affect rendering; the same view is 0.000% in the paired variant/light/dark captures, and variant-windows-swapclose.png is md5-identical between the two runs. All 25 other views identical (0.000%), including variant-windows-swapclose, variant-tabs-swapclose and both light/dark 01-window. Nothing intended to change visually, and nothing did.

Worth a reviewer's attention

1. This is a documentation fix, not a behaviour fix. Anyone who wanted actual Windows-style glyphs still does not get them; the change makes that explicit rather than delivering it. If maintainers prefer option (a), it needs new SVG assets in chrome/WhiteSur/titlebuttons/ guarded by @media (-moz-platform: windows), and it cannot be verified on this macOS harness at all — a Windows runner would be required. 2. My statements about Windows behaviour (parts/windows.css forcing list-style-image: none !important and setting .titlebar-close { order: -1 }, which this sheet flips to order: 1) are read from source, not measured — only the macOS half was measured live. 3. Untested claim I deliberately kept out of the README: whether moving the buttonbox to x=1193 on macOS drags the real native traffic lights with it (the buttonbox keeps appearance: auto, and Gecko screenshots do not capture OS-drawn window buttons, so I could not see it either way). The wording says only that Firefox hides its own buttons on macOS, which I did measure. 4. The one changed view in the visual comparison (extra-04-audio, 0.141%) is a flaky sound-indicator capture, flagged by the tool's own note during the run — I am reporting it rather than suppressing it, but I do not believe it is attributable to this change.

Closes #169.

_{Implemented and verified against Firefox 153.0.3 on macOS with fxcss. Every number above was read off a live browser, and the fix was seen working before this was opened.}

🤖 Generated with Claude Code

[github-actions]

Theme preview

Rendered from e6ba876 against the base branch.

Linux — no visual change

Nothing rendered differently. Current appearance:

macOS — no visual change

Nothing rendered differently. Current appearance:

Windows — no visual change

Nothing rendered differently. Current appearance:

No pixel differences on any platform — this PR does not change how the browser chrome renders in these views.

_{Views: browser window, focused address bar, find bar — each in light and dark. Native popups (app menu, context menus) are OS-level windows and cannot be captured. Workflow run}