Add PriceLevel::snapshot_by_insertion_seq; bump to 0.8.1 (#102)

[joaquinbejar]

Summary

PriceLevel exposed two order views, neither of which matches the order
match_order actually consumes liquidity:

• iter_orders() — DashMap-backed, non-stable order.
• snapshot_orders() — sorted by (timestamp, sequence).
• match_order → OrderQueue::match_front() — consumes by pure insertion
  sequence.

snapshot_orders() equals the sweep order only when timestamps are monotonic
with insertion (client-supplied / modify-restamped timestamps break that), so a
downstream self-trade-prevention pre-scan had no public primitive to predict the
sweep (issue #102). This adds one.

Changes

• PriceLevel::snapshot_by_insertion_seq() -> Vec<Arc<OrderType<()>>>
  (#[must_use]) — resting orders in ascending insertion sequence, i.e. the exact
  order match_order consumes them. Doc contrasts it with snapshot_orders()
  (timestamp order) and iter_orders() (unordered), and notes the same
  point-in-time caveat as snapshot_orders().
• OrderQueue::snapshot_by_seq() (pub(crate)) — the ascending index
  (SkipMap<seq, Id>) walk that match_front uses; factored out of the existing
  impl Serialize for OrderQueue (which now calls it — no duplication).
• Version bump 0.8.0 → 0.8.1 (additive, non-breaking).

No new exported type, no lib.rs/prelude.rs change, no migration guide, no
snapshot-format change, no match_order semantics change.

Testing

• test_snapshot_by_insertion_seq_matches_match_order_consumption — with
  non-monotonic timestamps (id 1 inserted first but timestamped later than id
  2): asserts the accessor yields insertion order [1, 2], equals the maker-id
  order match_order actually emits, and differs from snapshot_orders()
  ([2, 1]) — proving it predicts the sweep where snapshot_orders() does not.
• _empty_level, _partial_fill_keeps_front (KeepInPlace, same seq),
  _replenished_maker_moves_to_tail (ReplaceAtTail → new seq → last).

cargo test: 412 (lib) + 9 proptest + 1 integration + 9 doc, 0 failed.
cargo clippy --all-targets --all-features -- -D warnings, cargo fmt --all --check, cargo build --release, make doc (rustdoc -D warnings): all clean.

Checklist

• Additive, non-breaking; reuses the existing Serialize index-walk
• No # Errors (returns Vec); #[must_use]; doc'd vs the other two views
• Headline test proves equivalence to the real sweep under non-monotonic timestamps
• Version bumped to 0.8.1; no new deps; no behavior change

Closes #102

[Copilot]

Pull request overview

Adds a new public accessor on PriceLevel to snapshot resting orders in pure insertion-sequence order, matching the traversal/consumption order used by match_order (and diverging from timestamp-based ordering when timestamps are non-monotonic with insertion).

Changes:

• Add PriceLevel::snapshot_by_insertion_seq() as a public, #[must_use] accessor returning orders in ascending insertion sequence.
• Factor out the underlying index-walk into OrderQueue::snapshot_by_seq() and reuse it from impl Serialize for OrderQueue to avoid duplication.
• Add targeted regression tests for insertion-sequence snapshot behavior (including non-monotonic timestamps) and bump crate version to 0.8.1.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/price_level/level.rs	Adds snapshot_by_insertion_seq() with documentation contrasting it vs existing order views.
src/price_level/order_queue.rs	Implements snapshot_by_seq() (index walk) and reuses it in Serialize impl.
src/price_level/tests/level.rs	Adds regression tests asserting snapshot order matches match_order maker consumption order.
Cargo.toml	Bumps package version from 0.8.0 to 0.8.1.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/price_level/level.rs	92.81% <100.00%> (+0.03%)	⬆️
src/price_level/order_queue.rs	93.49% <100.00%> (+1.62%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.