fix: eliminate DiscreteFlyingEdgesClipper2D SMP garbage coords (+ per-thread vtkLabelMapLookup)

[akaszynski]

Follow-up to the SMP parity validator (#174). That validator found vtkDiscreteFlyingEdgesClipper2D emits garbage output point coordinates under cvista's default STDThread backend (same point count as serial, wild values — max coord dev ~3.4e37 on Linux / ~1.2e10 on macOS, varying run-to-run). This PR fixes that, plus removes two related shared-cache data races found along the way.

1. The real bug — counted-but-unwritten output points (the garbage coords)

Pass1/Pass2 (ClassifyXEdges/ClassifyYEdges) count an output point per classified dyad (Inside origins, x/y edge splits, interior points) purely from dyad classification — independent of whether the surrounding pixel forms a non-empty polygon case. But the point write (GenerateDyadPoints) only runs inside Pass4's if (numPolys > 0) branch. So an isolated single-label pixel (case 1 (1,0,0,0), numPolys==0) reserves a point slot in the prefix sum that Pass4 never writes.

Serial execution masked it: the fresh WriteVoidPointer buffer reads back as reproducible zeros, so the phantom points looked like harmless (0,0,0) orphans and serial-vs-serial was byte-identical. Under STDThread the point buffer lands on heap pages dirtied by worker scratch, so those unwritten slots read wild uninitialized floats — the observed symptom. The distinguishing difference from the race-free sibling vtkDiscreteFlyingEdges2D: that filter only counts intersections belonging to non-empty cases, so it never reserves an unwritten slot.

Fix: zero-initialize the NewPoints buffer right after allocation, so the never-written padding slots are deterministic (0,0,0) and identical to serial. Genuinely-used points are always written into per-row disjoint partitions, so real geometry is untouched. This eliminates the uninitialized-read UB and makes parallel output equal serial. (The phantom points still exist as unreferenced (0,0,0) orphans — a pre-existing logical over-count in the Flying-Edges counting, shared with stock VTK; this makes them deterministic rather than removing them. Removing the over-count is a deeper, riskier change left for later.)

2. Two shared-cache data races (defensive, ThreadSanitizer-flaggable)

Both vtkDiscreteFlyingEdgesClipper2D and vtkSurfaceNets3D's OUTPUT_STYLE_SELECTED path shared one vtkLabelMapLookup across all threads, whose cache (CachedValue/CachedOutValue) is written unsynchronized on every miss. Fixed by giving each SMP thread its own lookup via vtkSMPThreadLocal, mirroring how SurfaceNets3D's default BOUNDARY path already does it. (Note: the validator proved this race was not the cause of the garbage-coords symptom — #1 was — but it's a real race worth removing.)

Result

The smp-parity gate (#174) now gates vtkDiscreteFlyingEdgesClipper2D (moved out of known-issue) and it PASSES order-relaxed on Linux + macOS: gated-failures: 0. Its threaded geometry now equals serial and is run-to-run stable; only the emission order is thread-dependent, like the sibling DiscreteFlyingEdges filters.

🤖 Generated with Claude Code

[akaszynski]

Self-review ✅

Rebased onto main (dropped the squash-merged #174 commits); now main + 3 commits, 3 files changed.

Correctness — verified each change:

• e2a70c14 per-thread vtkLabelMapLookup: Clipper2D and SurfaceNets3D's SELECTED path each shared one lookup whose cache is written unsynchronized. Now each SMP thread owns one (vtkSMPThreadLocal, created in Pass1::Initialize / lazily in the SELECTED For, freed after). Mirrors SurfaceNets3D's already-correct BOUNDARY path. Confirmed no remaining this->LMap references (would've been a compile error). This removes a real race but — as the validator proved — is not the garbage-coords cause.
• 1ddeb655 zero-init NewPoints: the actual fix. Pass1/Pass2 count a point per classified dyad, but Pass4 only writes points in its numPolys>0 branch, so an isolated single-label pixel reserves a slot Pass4 never writes → uninitialized float (garbage under threads, masked serially by fresh-alloc zeros). std::fill_n(NewPoints, 3*totalPts, 0.0f) makes the never-written padding deterministic; genuinely-used points are always written into disjoint partitions, so real geometry is untouched. Minimal and low-risk. Known residual (documented): the phantom points still exist as unreferenced (0,0,0) orphans — a pre-existing over-count shared with stock VTK — now deterministic rather than removed.
• validator: Clipper2D moved out of the known-issue list and is now gated (order-relaxed).

CI evidence: SMP parity green on linux + macOS — vtkDiscreteFlyingEdgesClipper2D … PASS (order-relaxed), gated-failures: 0. Windows leg finishing.

Merging on green.