small fixes: fold the standing #185 review threads

[espg]

Folds the last standing adversarial-review threads from PR #185, which was rebase-merged before they were addressed. espg ruled in session (2026-08-16) that they be folded rather than left standing, so they land here on a fresh branch off main.

Refs #185 (the originating threads):

• small fixes: moc.rs densify shift wrap (#161) and the batch memory posture's missing input copy (#162) #185 (comment) — unreachable map_err arm + |e| shadowing in moc::batch
• small fixes: moc.rs densify shift wrap (#161) and the batch memory posture's missing input copy (#162) #185 (comment) — coverage::batch doc accuracy (misattached parenthetical, stale CHUNK peak claim)
• small fixes: moc.rs densify shift wrap (#161) and the batch memory posture's missing input copy (#162) #185 (comment) — the same parenthetical mirrored in mortie/batch.py, the conversion-copy floor, and the missing --mem harness

Refs #161, Refs #162.

Phases

• Name the defence-in-depth order arms (3d95c6f) — the review's live half of r3749046199.
• Give the batch-coverage memory table a --mem harness (fb4e175) — the live half of r3749049206.
• Verify the rest of those threads against post-merge main — see "Already folded" below.

What changed

1. 3d95c6f — defence-in-depth arms named. mocs_to_orders has two map_err(|msg| format!("moc {i}: {msg}")) arms, at validate_batch's budget estimate and in the parallel pass. Both are unreachable: the only Err to_order / to_order_count return is an out-of-range order, and validate_batch opens by refusing !(0..=29).contains(&order). They are kept as defence in depth against a future caller that reaches a kernel without that check, which is not something the next reader can tell from the code — so each now says so in a comment, pointing at the live arm (run_moc's ?, a malformed word) next to it. Comment-only; no behavior change.

2. fb4e175 — the memory table is re-runnable. polygons_to_morton_mocs' docstring and coverage::batch's module header quote a measured table (100k footprints → 6.9 MiB input, 12.9 MiB result, 21.9 MiB peak; 555,867 → 38.2 / 71.6 / 112.0), and benchmarks/measure_batch_coverage.py was timing-only, so the numbers rested on trust — unlike mocs_and, which cites benchmarks/measure_mocs_and.py --mem. That script now takes --mem N [order] and reports input, result and peak, plus both ratios, because the peak is input copy + result + one chunk and quoting it against the result alone omits the binding's to_vec().

It samples /proc/self/statm while the call runs — the method the docstring names, and a true peak rather than a watermark — falling back to the ru_maxrss high-water mark where /proc is absent, with the fallback named in the output so a lower bound is never mistaken for a peak:

$ python benchmarks/measure_batch_coverage.py --mem 20000 8
n=20000 order=8 cells=318029  [ru_maxrss watermark (lower bound; no /proc/self/statm)]
input  :      1.4 MiB   result:      2.6 MiB
peak   :      6.3 MiB   =  2.43x the result alone,  1.59x of input + result

Both docs now cite the harness at the table.

Already folded — verified, no change needed

Checked each remaining claim against post-merge main rather than against the thread text, since 1d7a412 ("fold review: stale CHUNK peak claim, conversion-copy floor, run_moc serial gap") landed between the review and the merge:

• |e| shadowing (r3749046199 point 2) — already |msg| at both call sites in 1d7a412.
• Misattached parenthetical (r3749047866 point 1, mirrored in r3749049206) — the header now reads "Those ratios stay near 1 because this path has no coarsen direction that can shrink the result to nothing — crate::moc::batch's densify does, and reaches 60x there"; the clauses attach to here, as the review asked.
• Stale CHUNK peak claim (r3749047866 point 2) — now "~1.1x of input + result (the module header's model; that sweep quoted it against the result alone, which omits the input copy)". The arithmetic checks: 21.9 / (6.9 + 12.9) = 1.11.
• Conversion-copy floor (r3749049206) — the docstring already calls the second resident copy a floor and names float32 / lists / non-contiguous slices as adding another on top.

Testing

• cargo fmt --check clean; cargo clippy --all-targets reports nothing on either touched Rust file; cargo test --lib 374 passed / 0 failed / 1 ignored.
• pytest mortie/tests 1492 passed / 40 skipped / 0 failed.
• flake8 mortie --select=E9,F63,F7,F82 clean; flake8 benchmarks/measure_batch_coverage.py --max-line-length=88 clean.
• benchmarks/measure_batch_coverage.py --mem 20000 8 run end to end (output above).

Questions for review

• The --mem case was verified only on its macOS fallback path — this machine has no /proc/self/statm, so the statm sampler that reproduces the documented numbers is exercised by construction, not by a run. Worth one Linux run before trusting the table's reproducibility end to end.
• The --mem addition answers a review ask for a harness rather than a defect. If it reads as scope creep for a small-fixes PR, fb4e175 can be dropped on its own and the two doc citations reverted with it.

[github-actions]

⚠️ [ruff] <D401> _{reported by reviewdog 🐶}
First line of docstring should be in imperative mood: "Current resident set size in MiB, or None where it is unreadable."

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.34%. Comparing base (47d9e8a) to head (fb4e175).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #191   +/-   ##
=======================================
  Coverage   96.34%   96.34%           
=======================================
  Files          18       18           
  Lines        1996     1996           
=======================================
  Hits         1923     1923           
  Misses         73       73           

Flag	Coverage Δ
unittests	96.34% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
mortie/batch.py	100.00% <ø> (ø)

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47d9e8a...fb4e175. Read the comment docs.

🚀 New features to boost your workflow:

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

[espg]

🤖 from Claude

Status: both phases are landed and CI is clean — 16 checks passing, 0 failing, with only the long-running "Rust benchmarks" job still going at the time of writing.

Marked waiting rather than flipping to ready-for-review, on two counts: there are open questions in the PR body that need an espg call (the --mem sampler is verified only on its macOS fallback path, and fb4e175 answers a review ask for a harness rather than a defect, so it is droppable if it reads as scope creep), and per CLAUDE.md §6 marking a PR ready is an espg-only action here.

Left in draft.

[codspeed-hq]

Merging this PR will improve performance by 11.64%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 70 untouched benchmarks
⏩ 1 skipped benchmark¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	coverage_square[4]	164.1 µs	147 µs	+11.64%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing claude/small-fixes-2026-08-16 (fb4e175) with main (47d9e8a)}

Footnotes

1. 1 benchmark was skipped, so the baseline result was used instead. If it was deleted from the codebase, click here and archive it to remove it from the performance reports. ↩