fix(Tunnel): render tunnelled children in the first commit

[mfal]

Part of #3015. Split out of the original PR: this one carries only the react-tunnel defect and its tests. The docs and story fixes moved to #3050.

The defect: react-tunnel dropped tunnelled children from the first commit

Slider tunnels its <Label> into the value row. TunnelExit fell back to render-phase children only while useIsSSR() was true — never the case on a client-only mount. So the first commit contained no <label> at all, react-aria's useSlot concluded there was none, and warned. The slider genuinely had no accessible name until the next render.

Introduced in de72c80 (#2827), which replaced the ungated getEntries(id) with an isSsr-gated read and so kept only the server half of the bridge its own comment describes. The fix restores the client half: the flag is flipped in a layout effect, never during render, so repeated render invocations before a commit (StrictMode double-invoke, concurrent re-render) all read the same value and SSR hydration stays free of mismatches. From the first commit on, the committed children stay authoritative — even when empty.

This affects every tunnelled slot, not just Slider.

Verified

• Both new tests are red without the fix and green with it.
• pnpm nx test:browser react-tunnel 23/23 on this branch, rebased onto current main (1.1.4).
• eslint + prettier clean on every changed file.

No visual test was added: the settled DOM is unchanged — only the first pre-paint frame differs. run-visual-tests is on this PR so the suite confirms that rather than us assuming it.

🤖 Generated with Claude Code

[github-actions]

Coverage Report for ./packages/components/

Status	Category	Percentage	Covered / Total
🔵	Lines	78.69%	746 / 948
🔵	Statements	78.57%	763 / 971
🔵	Functions	80.09%	165 / 206
🔵	Branches	70.33%	377 / 536

File Coverage

No changed files found.

Generated in workflow #6561 for commit 75053fa by the Vitest Coverage Report Action

[github-actions]

✅ Visual Regression Tests Passed

All visual snapshots match the committed baselines.

Run details

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

Type	URL
docs	pr-3022.docs.review.flow-components.de
storybook	pr-3022.storybook.review.flow-components.de

Images:

• docs: ghcr.io/mittwald/flow/docs:pr-3022
• storybook: ghcr.io/mittwald/flow/storybook:pr-3022

[github-actions]

✅ Cross-Version Tests Passed

The current host still renders old published remote versions correctly (iframe) and in the same DOM shape (in-process).

Iframe harness (attribute-accurate): ✅ passed

In-process harness (structure-only): ✅ passed

Run details

[mfal]

Two different failures in one shard — and one of them may not be this branch's

run-visual-tests (4) reports 109 capture timeouts and 3 real pixel diffs. Those need separating.

The 109 are infrastructure, not this PR

All of them are Could not capture a stable screenshot within 5000ms, with no comparison performed, spread across unrelated components. The runner is the cause: this shard spent 815 s in tests against ~80 s on a healthy run. The same signature is currently on main itself (run 33503916049, one shard red, one capture timeout, zero pixel diffs), on #3025 (84 timeouts in one shard), and it aborted #3025's update-screenshots run mid-step. Hundreds of timeouts across several PRs and main, zero pixel diffs among them.

Worth naming: while the runners are this slow, the update-screenshots label is actively dangerous — it runs --update over the whole suite and commits whatever it captures. On #3025 the update step failed before the commit step, which is the only reason nothing was written. That was luck, not a safeguard.

The 3 are real, and probably predate this branch

List empty search views, firefox only (so the dark theme), in (Local) and (Remote), 3256 px / ratio 0.01. Both environments failing together is the signature of a genuine difference rather than a race — a race costs one environment, per this package's own scenarioFocus.ts.

But the likely cause may be main, not this branch:

• This branch now carries only the TunnelExit change.
• main gained fix(Heading): space tunneled content without :has() #3046, fix(Heading): space tunneled content without :has(), merged 11:12 UTC — which touches exactly the same thing, the spacing of tunneled content.
• The last scheduled visual run, the one that covers firefox, was at 08:09 UTC — three hours before fix(Heading): space tunneled content without :has() #3046 landed. The required per-PR shards run webkit only, so nothing has exercised firefox on main since fix(Heading): space tunneled content without :has() #3046.

So a firefox-only regression from #3046 would currently be invisible on main and would surface on the first branch whose label run touches firefox — which is this one.

The decisive test costs one run: trigger the visual suite with firefox on current main (scheduled workflow, or the label on a no-op PR). If List empty search views fails there too, it belongs to #3046 and not here.

I have not re-run anything for the 109, since with the runners in this state a rerun is a coin flip rather than a fix.

🤖 Addressed by Claude Code