Cross-process layout nondeterminism: hashed-collection order leaks into geometry (at least zenuml)

[clintecker]

Surfaced by the new LinuxGoldenTests (commit that added it): the same source can render a hair differently across process launches, because Swift randomizes the Set/Dictionary hash seed per process and a few layouts iterate a hashed collection in a way that reaches coordinates.

Evidence: running the golden test alone passed (one process), but running it inside the full swift test failed on zenuml (~0.64% of pixels differ) — a different process, different seed. Setting SWIFT_DETERMINISTIC_HASHING=1 makes rendering reproducible and the goldens stable (that's how CI/scripts/test-linux.sh run), which confirms the cause.

Why StabilityTests miss it: StabilityTests.testLayoutIsDeterministicAcrossRuns compares two layout calls within one process (same seed), so hash-order-dependent output looks stable there. The property that actually matters to users — same source → same pixels in two different app launches — isn't covered.

Impact: minor. Visual only (element ordering/positions shift slightly), no correctness effect, and only in the layouts that iterate hashed collections into geometry. The flowchart engine uses model-order tie-breaks throughout and appears unaffected; zenuml is confirmed affected, likely a couple of others.

Fix direction: audit layouts (start with DiagramLayoutZenUML.swift) for Set/Dictionary iteration whose order influences positions, and sort / use model order before iterating — the same discipline the flowchart engine already follows. Then the "deterministic layout" property holds for users, not just under the test's fixed seed, and SWIFT_DETERMINISTIC_HASHING becomes belt-and-suspenders rather than load-bearing.

Note for the sibling Vinculum engine: if its math layout uses hashed collections anywhere glyph positions are derived, it has the same latent issue.

[clintecker]

Stronger evidence from wiring up the golden-image CI gate: the nondeterminism is test-execution-order dependent and survives SWIFT_DETERMINISTIC_HASHING=1, so it's not only the hash seed.

• Rendering a fixture with swift test --filter LinuxGoldenTests (golden test alone) produces bytes X.
• Rendering the same fixture in the full swift test run (golden test after the other suites) produces bytes Y ≠ X (~0.7–4% of pixels), with the fixed hash seed set in both.
• Confirmed arch-independent: identical diffs on x86_64 and arm64 runners, and the CI arm64 render matched the maintainer's Apple-silicon render exactly — the only variable that moved the pixels was alone-vs-full-suite.

So some layout carries state that depends on what ran before it — a global/allocation-ordered value (not just Set/Dictionary seed) reaching coordinates. SWIFT_DETERMINISTIC_HASHING fixes the hash-seed half but not this.

Consequence: a pixel golden gate isn't viable until this is fixed — the goldens can't be stable when the render depends on execution context. I'm holding the golden-image CI gate (the test + workflow) until this is resolved; the approach is captured in docs/notes/linux-rendering-via-silica.md and can be re-landed once the render is a pure function of the source.

Fix direction unchanged but broadened: audit for any ordering-dependent state (hashed-collection iteration AND process-global/allocation-ordered values) that influences geometry; make layout a pure function of the parsed model.