fix: 4D negative-orientation cell during batch construction (88% vertex skip rate)

[acgetchell]

Summary

During 4D 100-point batch construction, a cell (CellKey(29v7), vertices [6v1, 2v1, 9v1, 11v1, 7v1]) is created with orientation=-1 (negative geometric orientation). This cell persists throughout construction and causes 88 of 100 subsequent vertex insertions to be skipped as degeneracies.

Reproducer

DELAUNAY_LARGE_DEBUG_N_4D=100 DELAUNAY_LARGE_DEBUG_ALLOW_SKIPS=1 \
  cargo test --release --test large_scale_debug debug_large_scale_4d \
  -- --ignored --nocapture

• Seed: 0x9B7786C999C56A16, ball distribution (radius=100)
• Only 12 of 100 vertices inserted (12% success rate)
• All 88 skips hit the same cell with orientation=-1
• The resulting 12-vertex triangulation passes L1–L4 validation
• In debug mode, PLManifoldStrict validation produces ~250+ identical warnings for this cell at ~2s intervals, causing extreme slowness that looks like a hang

Root Cause Hypothesis

The cell is created during Bowyer-Watson cavity filling without proper orientation normalization. In 3D, orientation is canonicalized post-insertion (cells are reordered to positive orientation), but the 4D path may be missing this normalization step.

Investigation Steps

1. Trace cell creation: determine which insertion index first creates CellKey(29v7) with negative orientation
2. Check if orientation normalization (normalize_cell_orientation or equivalent) is applied in the 4D cavity-filling code path
3. Compare the 3D and 4D orientation normalization paths for discrepancies

Fix Strategy

Ensure orientation normalization is applied to all newly created cells in the cavity-filling code, regardless of dimension. This should be straightforward if the normalization exists for 3D but is missing or conditional for 4D.

Secondary Issue: Debug-Mode Warning Spam

The negative-orientation cell causes PLManifoldStrict validation to emit ~250+ identical warnings. Consider rate-limiting or deduplicating these warnings to prevent debug-mode runs from appearing hung.

References

• Discovered during Debug large-scale 3D/4D runs: incremental-bisect and 1000-vertex cases #204 debug runs
• Related: feat: dedicated targeted topology repair stages (ridge, vertex-link) #304 (topology repair stages)
• Test file: tests/large_scale_debug.rs
• Cavity filling: src/core/algorithms/incremental_insertion.rs
• Orientation normalization: src/core/triangulation.rs
• Known issues: docs/KNOWN_ISSUES_4D.md

Co-Authored-By: Oz oz-agent@warp.dev

[acgetchell]

Update: 3D manifestation at 1000 vertices

While fixing #306 (release-mode flip-repair constants), we discovered this orientation issue also affects 3D at scale, not just 4D.

Reproducer

DELAUNAY_LARGE_DEBUG_N_3D=1000 cargo test --release --test large_scale_debug debug_large_scale_3d -- --ignored --exact --nocapture

Default seed 0xE30C78582376677C, ball distribution (radius=100).

Result

All 7 construction attempts (1 original + 6 shuffled retries) fail with:

PL-manifold validation failed after construction: Negative geometric orientation:
Cell f301d10c-c0ec-4773-8dc9-64e5e9bafb51 (key CellKey(1449v15),
vertices [VertexKey(29v1), VertexKey(197v1), VertexKey(370v1), VertexKey(84v1)])
has negative geometric orientation; expected positive canonical orientation

Total wall time: ~82 seconds across 7 attempts (~12s each).

Analysis

The root cause is likely the same as the 4D case: cavity fill (fill_cavity) creates cells without proper orientation normalization, and normalize_and_promote_positive_orientation doesn't fix all residual negative cells before validation runs.

This is distinct from #306 (flip-repair cycling due to release-mode constants), which is fixed in the fix/306-unify-release-repair-constants branch. The orientation issue is the next blocker for v0.7.6 — it affects both 3D performance (#310, since all retry attempts fail) and correctness.

Co-Authored-By: Oz oz-agent@warp.dev