fix: decode correct block lamport range end to avoid checkout hang

[zxch3n]

Summary

Fixes an infinite loop in ChangeStore::get_change_by_lamport_lte that hangs checkout after importing a snapshot.

Repro: a single commit whose ops span more than MAX_BLOCK_SIZE * 8 lamports (so the change is split across multiple change-store blocks and lamport lookups engage the binary-search path), exported as a snapshot, imported into a fresh doc, then checked out to an old frontier. The movable-list diff calculator resolves historical positions via MovableListHistoryCache::last_pos → OpLog::idlp_to_id, which never returns.

Root cause

ChangesBlock::from_bytes set lamport_range.1 to header.lamports.last(). But header.lamports only stores the start lamport of each change (n entries), unlike header.counters which has n + 1 entries ending with the block's end counter. For single-change blocks (the common case when a big change is block-split) the decoded lamport range was empty, e.g. (0, 0) for a block really spanning lamports 0..3939.

The hand-rolled binary search in get_change_by_lamport_lte then classified the block containing the target lamport as "entirely below target" (lamport_range.1 <= target), and since lower_bound = (lower + upper) / 2 is a fixed point once upper == lower + 1, it spun forever with no progress.

Blocks built via the local append path (push_change) and decode_block_range already computed the end correctly; only the from_bytes decode path was wrong, which is why only imported docs hang.

Changes

• ChangesBlock::from_bytes: compute the exclusive end lamport as the last change's start lamport plus its length (derived from header.counters), returning Err on malformed input instead of panicking.
• Harden the binary search: cap its steps and fall back to the (always correct) external kv scan if it fails to converge, so inconsistent block metadata can degrade to a slower lookup instead of a hang.
• Regression tests:
  • decoded_block_lamport_range_matches_counter_range (loro-internal unit test) pins the decoded block metadata and exercises lamport lookups across the binary-search path; it fails fast (assert, no hang) if the decode bug is reintroduced.
  • checkout_after_importing_block_split_change (crates/loro integration test) reproduces the original user scenario end-to-end.
• Changeset for loro-crdt (patch).

Validation

• Both new tests fail (fast, no hang) with the fix reverted and pass with it applied.
• cargo test -p loro-internal --lib: 295 passed.
• cargo test -p loro --test change_store_test, checkout-related loro_rust_test filters: pass.
• cargo fmt clean on touched files.

🤖 Generated with Claude Code

[github-actions]

WASM Size Report

• Original size: 3053.29 KB
• Gzipped size: 1009.20 KB
• Brotli size: 707.65 KB

[zxch3n]

Addressed a review finding in d642be3: when the lamport binary search bails out (step cap or hole), the fallback only scanned external_kv, but local changes can exist solely in mem_parsed_kv before a flush — so a lookup targeting a lamport gap (peer 1 change → large imported peer 2 change → another peer 1 change) incorrectly returned None until compact_change_store() ran (also visible as WASM getChangeAtLamport returning undefined).

The fallback now collects a candidate block from both mem_parsed_kv and external_kv (bounded by the search's upper_bound) and uses the one with the greatest start counter — within a peer, lamport grows with counter, so that block holds the greatest matching lamport. On a tie the in-memory block wins, since it may contain unflushed changes appended after the flushed copy.

Added lamport_lookup_finds_unflushed_mem_blocks reproducing the scenario before any flush; it fails with the external-only fallback and passes now. Full cargo test -p loro-internal --lib (296) and the integration suite still pass.