The one-construction arms report a tally, so a CI-only duplicate names no caller

Context

Split out of #18275 so that ticket keeps its honest close target. #18275 is "the duplicate happens" and its AC-1 is a reproduction nobody has. This is the separable, already-deliverable half: "when it happens, the failure says nothing about who caused it." PR #18280 delivers this one and only this one.

Live latest-open sweep: checked the latest 20 open issues at 2026-09-04T14:37Z; no equivalent. Own-assignment sweep: 8 open, nearest is #18215 (a different unstable arm, same absorbed-by-re-run shape). A2A claim sweep over the last hour shows no claim on this scope. Memory Core semantic sweep run on #18275's nouns earlier this turn: 8 results, none on this surface.

The Problem

DockRailLazyModule.spec.mjs asserts the single-construction contract twice, and both assertions carry only a count:

expect(instances, 'one construction').toBe(1)

When it fails, the message says a duplicate happened. It cannot say who caused it — and two callers may legitimately load a parked pane:

• layout.Card#afterSetActiveIndex loads it when its index activates;
• container.Base#insert starts the load itself when the inserted index is already the active one.

A tally of 2 does not distinguish them. That matters here more than it usually would, because the duplicate surfaces roughly once in a hundred runs and only on a loaded CI runner — measured: 275 local runs green, including 40×8-worker contention. There is no session to attach to afterwards, and the passing re-run that follows destroys the state. The failure message is the only channel that reaches a reader.

Two dev reds today (33852876846, 33854077715) each produced a bare Error: one construction and nothing else. That is the whole diagnostic yield of an event we wait a hundred runs for.

The Architectural Reality

• test/playwright/component/apps/dock-lazy-rail/LazyPane.mjs — static instances is the identity witness; it counts and discards everything else.
• test/playwright/component/apps/dock-lazy-rail/app.mjs — lazyPaneInstances exposes that count to the spec through Neo.worker.App.getConfigs.
• test/playwright/component/dashboard/DockRailLazyModule.spec.mjs:118,141 — the two assertion sites.

The construction happens inside the app worker; the spec runs in the main realm. A main-realm probe cannot see the class at all (Neo.ns(...) returns undefined there), so any witness has to be captured worker-side and cross the boundary as data.

The Fix

Capture one call site per construction on LazyPane, expose it as a spec-readable witness beside the count, and have the assertion carry it in the failure message — read only on the failing path, so the green path keeps its single round-trip.

Acceptance Criteria

• AC-1 — a second construction produces a failure message containing a call site per construction, not just a count.
• AC-2 — the witness is proven to carry usable frames across the worker boundary, rather than assumed: the trail arrives as strings and matches the callers that distinguish the two load paths. A diagnostic that renders empty on the failing path is worse than none, because it reads as "no second caller".
• AC-3 — the green path is unchanged: the existing five arms still pass, and the trail is not fetched when the count is correct.

Out of Scope

• Reproducing or fixing the duplicate itself. That is #18275, and it stays open.
• The other unstable arms (#18121, #18215). Same absorbed-by-re-run shape, different subjects, separately owned.

Avoided Traps

• Asserting the witness instead of proving it. The first attempt to force a red here called Neo.ns(...) from page.evaluate — main realm, where the worker-side class does not exist — and failed with Class undefined does not exist. That is an instrument bug wearing a subject bug's clothes, and the green that follows it is not evidence.
• Fetching the trail unconditionally. It costs a round-trip per arm to carry information only the failing path uses.

Related

• #18275 — the duplicate itself; this ticket is its diagnostic half, not its fix.
• #18084 / #18201 — the insert-side parked load and the in-flight dedup that created and then narrowed the two-caller seam.
• #18121, #18215 — sibling unstable arms.

Origin Session ID: 7596538d-5324-419a-b043-95c585d833ea

Retrieval Hint: the one-construction arms carry a tally but no caller identity — worker-side construction trail, CI-only duplicate, split from #18275