Fix clearBound corrupting prevBound.extent on singleton SharedBound removal (#143)

[mikesol]

Root cause

clearBound in Deku.Internal.Region has two branches — the first branch is taken when the preceding SharedBound is larger (or we're at the first region), and it extends prevBound to cover the nextBound:

void $ ST.write extentToEff prevBound.extent   -- BUG
runSTFn4 fixManagedTo selfIx (extentToIx + 1) (updateShared prevBound) children

extentToEff is a live STRef — it's ST.read managed.ixRef on the removed region. When the removed region is the sole member of its SharedBound (extentToIx == selfIx), fixManagedTo is a no-op (backwards range), and then pushIx(-1) fires on the removed region, making that ref resolve to -1. From that point on, prevBound.extent returns -1, so isLastBound never fires for survivors, and a subsequent bump fails to propagate end to the parent span.

The exact failure sequence from the issue (add C0, add C1, undo C1, undo C0, add C0 again, observe broken placement) maps to: r1.bump, r2.bump, r2.remove (singleton clear → corrupts prevBound.extent), r1.remove (isLastBound broken, updateParent never fires), r3.bump (end not notified).

Fix

Only write extentToEff into prevBound.extent when extentToIx > selfIx — i.e. when there are actually surviving regions beyond the removed one that now belong to prevBound:

runSTFn4 fixManagedTo selfIx (extentToIx + 1) (updateShared prevBound) children
when (extentToIx > selfIx) do
  void $ ST.write extentToEff prevBound.extent

Tests

Added a regression test in index.test.js covering the exact sequence: add, add, remove-last, remove-first, add — verifying that end propagates correctly to the parent span after the full cycle.

Note: the pre-existing sendTo test failure is unrelated to this PR.

🤖 Generated with Claude Code