test(super-editor): remove dead layout-resolved mocks and add alignment tests

[tupizz]

Summary

Applies testing-excellence principles to the SD-2563 test suite. Two independent changes:

1. Remove dead @superdoc/layout-resolved mock stubs (Iron Law #3)

11 test files carried a vi.mock('@superdoc/layout-resolved') block that no test depends on. Verified empirically: after removing all 11, the full super-editor suite (11,348 tests) still passes.

These stubs were added during PRs 9/10 as import-time plumbing but were never load-bearing. Anti-pattern: "mocking without understanding."

Kept the stubs in 2 files whose tests genuinely rely on controlled resolveLayout behavior:

• PresentationEditor.footnotesPmMarkers.test.ts — asserts specific data is passed to resolveLayout
• PresentationEditor.sectionPageStyles.test.ts — exercises layout paths where real resolver would fail on minimal fixtures

2. New alignment test file covers two previously-untested risk areas

HeaderFooterSessionManager.alignment.test.ts adds two tests:

Test A: rId-based path delivers items aligned 1:1 with fragments

PR 10's original implementer explicitly flagged this as uncovered — only the variant-based (by-type) path had a test. The rId-based path (multi-section documents) shares the same alignment contract but a different code path. This test seeds headerLayoutsByRId via a mocked layoutPerRIdHeaderFooters, lets the real resolveHeaderFooterLayout run downstream, and asserts payload.items[i] corresponds to payload.fragments[i].

Test B: Length-mismatch guard drops items and warns

The runtime safety net at HeaderFooterSessionManager.ts:1702-1707 and :1763-1765 is the last line of defense against alignment corruption. Before this PR, nothing verified it fires correctly. This test stubs the resolver to return 2 items for 1 fragment (a divergence only possible from a resolver bug), asserts payload.items === undefined (items dropped), and asserts console.warn was called with the expected guard message.

Why this matters

The 12-PR stack for SD-2563 made the painter "dumb" but relied heavily on layout comparison (407/407 byte-identical) for confidence. These two unit tests protect the specific behavioral contracts that layout-compare can't cheaply verify:

• Which code path delivers items (rId vs variant)
• What happens when the contract is violated (the guard)

Test plan

• 11,350/11,361 super-editor tests pass (11,348 existing + 2 new, 13 pre-existing skipped)
• super-editor build clean
• New tests assert on observable outcomes only, not mock calls (Iron Law encapsulate pdf viewer styles #1)
• Tests use real production code for the path they cover, stub only the specific signal they need

Stack

#	PR	Title	Status
1	#2810	Lift page metadata
...		(PRs 2-11 omitted for brevity)
12	#2829	Delete dead hash helpers
13	this	Testing cleanup + alignment tests	👈 this PR

PR Stack (SD-2563: Dumb Painter Refactor)

#	PR	Title	Status
1	#2810	Lift page metadata into ResolvedPage
2	#2811	Lift fragment metadata into resolved paint items
3	#2812	Pre-compute SDT container keys in resolved layout
4	#2813	Pre-compute paragraph border data in resolved layout
5	#2814	Move change detection into resolved layout stage
6	#2818	Lift paragraph/list block and measure into resolved items
7	#2819	Extract block/measure resolution helper
8	#2820	Remove body blocks/measures from DomPainterInput
9	#2826	Add resolveHeaderFooterLayout helper
10	#2827	Deliver resolved items to decoration provider callback
11	#2828	Remove blockLookup — painter reads only resolved data
12	#2829	Delete dead hash helpers after blockLookup removal
13	#2845	Testing cleanup + alignment tests	👈 this PR
14	#2853	Remove legacy createDomPainter wrapper API

[linear]

SD-2563 Painter refactor: clear inputs/outputs - "dumb" painter