Replace BTreeMap in PortConnectivity with a sorted Vec; semi-naive iteration replacing in-place updates

[frankmcsherry]

PortConnectivity now stores a sorted Vec<(usize, Antichain<TS>)> with lazy consolidation (appends set a dirty bit; reads expect consolidated data, with freeze points at Builder::add_node and PerOperatorState::new). The summarize_outputs fixed point is restructured into semi-naive rounds over log-structured sorted runs, removing its HashMap accumulator; the changed-bit insert methods it required are removed as dead.

This excises all BTreeMap (and the one HashMap) instantiations from the progress subsystem: generated IR for the bfs example drops 9.1% (254,560 -> 231,310 llvm-lines; btree machinery 8,723 -> 0). Construction remains O(n log n) under any insertion order; shape_scaling timings at 10k/100k operators are unchanged or slightly improved.

(ed: there are some O(n log^2 n) datastructures now, to avoid a one-off LSM implementation)

Measurements

All on master @ 0b23c249 vs this PR @ 1024c32d, release builds,
Apple Silicon (darwin 25.1.0). Scaling tests timed over 3 runs each;
RSS sampled via ps after construction completes, 2 runs each.

Generated code (bfs example):

	master	PR	Δ
cargo llvm-lines total	254,560 lines / 5,092 copies	236,657 / 5,034	−7.0%
post-opt IR, function bodies	252,020 lines	230,458	−8.6%
BTreeMap machinery	8,723 lines / 10 fns	0 / 0	−100%

Construction scaling (tests/shape_scaling.rs, with temporary 1M variants):

Test	master	PR	Δ
operator_scaling 1M	3.87–4.17s	2.63–2.99s	−32%
subgraph_scaling 1M	4.67–4.69s	3.07s	−34%
operator_scaling 100k	0.34s	0.25–0.26s	−24%
subgraph_scaling 100k	0.38–0.39s	0.28–0.29s	−26%

Both sides scale ≈11–12× from 100k → 1M (log factors, no quadratic
behavior on either side).

event_driven 1000 × 1000:

	master	PR	Δ
peak RSS after build	5,376 MB	4,321 MB	−1,055 MB (−19.6%)
dataflow build time	1.53–1.56s	1.50–1.53s	parity / slightly better