Give CSS sole ownership of overlay visibility

[pathscale]

Three commits that were sitting on a local branch and never reached a pull request. Rebased onto current master, where the bug is still live.

The bug

createOverlayPosition seeded its style signal with an inline visibility: hidden and restored it whenever the overlay closed. That inline style outranks each component's [data-open="true"] CSS, and portal refs can settle after the open signal — so a Select or Popover that is semantically open could be left invisible and unoperable, with nothing in the DOM to suggest why.

Positioning now writes no visibility at all. Visibility belongs to the data-open contract, and one owner is the whole point.

The other two

• fix(select): defer compound children under context — compound children were built before the context they read existed.
• fix(select): keep listbox in the renderer tree — the listbox left the renderer tree when closed, so the positioning effect had no element to measure on the frame it reopened.

Verified

bun run build and the full suite — 164 tests, 0 failures — on this branch. Master builds too, so the comparison is like for like.

One conflict on rebase, in Select.layout.tsx: master has since added a <Show> and an untrack the original commits predate. Resolved by checking what the merged file actually uses rather than taking a side — both imports are needed and are kept. The first attempt dropped untrack, which the declaration build caught.

Audit note

This came out of a sweep of 19 local branches in this repo. Only four had anything genuinely unlanded once compared by patch content rather than commit count — one branch was 21 commits "ahead" and entirely replayed history. Of those four, the glass-material work is superseded by what is already on master (_shared/material.css there is 283 lines to the branch's 115), and two more target Surface, a component master no longer has. This is the only branch with work worth keeping.

[pathscale]

The failing build check here is not caused by this pull request, and it is worth knowing because master is currently red for the same reason.

The failure is in the Install native QA tools step: qa-inspect-host v0.1.8 will not compile, because its dependency graph now resolves two engine versions at once — ps-blitz-script 0.3.6 and 0.4.0 — alongside tauri-runtime-blitz 0.3.2. That is the dual-engine mismatch, and it surfaces as a ScriptDocument type error against snapshot_document.

Three TypeScript files cannot produce a Rust type error, so I tested it rather than asserting it: I re-ran master's own build, unchanged, with today's dependencies.

	result
master at 09:40 today	pass
master re-run just now, same commit	fail, identical error

So the cause is upstream version drift since this morning — ps-blitz-script 0.4.0 appearing in the graph — and it will keep failing on every pull request here until the QA tool's resolution is pinned or bumped.

This branch itself is clean: bun run build completes and the suite passes 164 tests, 0 failures locally, and bun run check reports all 94 components passing contract checks.

[pathscale]

Answering the fair question of whether this was verified or assumed: it was assumed, so I went and verified it — and found the QA harness could not render anything at all.

The harness was dead, on master too

Every page rendered an empty body, with Cannot read properties of undefined (reading 'spec') thrown from inside the runtime — a component invoked with no props, and the reactive system halting behind it.

@rsbuild/plugin-solid injects solid-refresh, whose $$component wrapper calls createSignal(component). Solid 2 reads a function initialiser as a derivation and builds a computed for it, and a computed needs an owner. So the wrapper broke every component the harness defines, Harness among them. Babel performs the same transform without the refresh runtime, and moduleName stays for the reason the original comment gave.

This is the tool meant to catch a component rendering nothing, and it could not render anything itself.

Which makes the actual fix checkable

With the harness working, the claim in this pull request is observable rather than merely tested:

Select	data-open	visibility	inline override	height
closed	false	hidden	none	0
after click	true	visible	none	86px

Popover behaves the same: panel paints at 40px, visibility: visible.

The inline override is the point. Before, positioning seeded visibility: hidden and outranked the component's [data-open="true"] CSS; now there is no inline visibility at all and CSS owns it.

Suite still passes: 164 tests, 0 failures.