e2e lane red on main since #524: a dropped landing node doesn't scroll with the page

[AndresL230]

What

frontend/e2e/landing-drag-field.spec.ts:332 — "a dropped node stays where it was put, and scrolls with the page" — fails on main, and has since the landing-v5 port (#524) merged on 2026-08-16. The e2e (browser lane) workflow on main has been red ever since; the run before #524 (docs: handoff — F is merged, 2026-08-14) was the last green one.

The assertion that fails

Not the sway check — the scroll-follow one, landing-drag-field.spec.ts:353-354:

await page.evaluate(() => window.scrollBy(0, 300));
await page.waitForTimeout(600);
const scrolled = await probe(page);
expect(Math.hypot(scrolled.x - settled.x, scrolled.y - (settled.y - 300)))
 .toBeLessThan(SWAY_PX); // SWAY_PX = 12

Error: expect(received).toBeLessThan(expected)
Expected: < 12
Received: 98.20082315228477

The first assertion (the node settles within its sway envelope after the drop) passes. So the node stays where it was put; it just doesn't travel with the document on scroll — it ends up ~98px away from where a page-anchored node should be after a 300px scroll.

Reproduction

Deterministic, not flaky — it fails identically in two places:

• CI, run 31975087515 on the feat(landing): port Sapling Landing v5 #524 merge commit: failed on all three retries.
• Locally, twice in a row on the full stack (make e2e-up → npx playwright test), same line, same magnitude. Everything else is green: 47 passed, oracles 0 findings, integration 47 passed.

Why it needs a decision, not just a fix

Two possibilities and they lead opposite ways:

1. The product is wrong — a dropped node in the v5 drag field is positioned in a way that doesn't track document scroll (viewport-fixed rather than page-anchored). Then the test is doing its job and the landing has a real bug.
2. The test is wrong — the v5 port deliberately changed the anchoring model, and this journey still encodes the pre-port contract. Then the assertion needs updating in the same commit, with a comment saying why.

Worth resolving quickly either way: while this is red, the e2e lane on main gives no signal at all, so the next real regression it catches will look like more of the same noise.

Not related to

Found while running the pre-merge E2E cycle for #563 (quiz addendum Part 2). That PR touches no frontend code and the failure reproduces on main without it.

[AndresL230]

Diagnosed — it's option 2: the test was wrong

Credit to a parallel session that instrumented this rather than guessing. Recording it here so the issue stops reading as an open question.

faq is the only section in DragField's TRACKS. syncClusters() positions a tracked cluster at field.top + a.top + dy where dy = (track.top - field.top) - trackTop, which collapses to cluster_y = track.top + const — so the cluster is welded to the FAQ question column, and that column is sticky; top:110.

Measured over the journey's own 300px scroll:

	delta
scrollY	+300
#faq top	−300
track top	−202.81 (hit its pin partway)
cluster top	−202.80
node y	−202.60
error	97.40

That matches CI's 98.2. The column had exactly 202.81px of travel left before pinning, so ~97px of the scroll happened with the copy held still — and the cluster correctly held still with it.

So the product is right and the weld is deliberate (8bb34869 — the clusters had been sliding 374px out from under their words). The journey asserted raw scrollY against the one cluster where 1:1 page coupling is untrue; it picked cluster 4 for elbow room, without knowing faq is also the only tracked field.

Fix: re-frame the assertion against the weld, reading the target from the field's own data-drag-track so it falls back to the field itself (the plain 1:1 reference) if the weld is ever dropped. In progress on fix/566-drag-field-weld-frame.

Worth keeping the P1: the browser lane on main stays red until this lands, and a red lane gives no signal on anything else.