[emattei]

#18 taught scan_fasta to filter, but scan() had already built both
strings of every Hit and pushed it into a per-contig Vec, so memory
still rose with every match rather than with the ones worth keeping. The
PAM is now read off the raw bytes, in guide orientation, before anything
is allocated.

It is not faster. 1,000 9-mers against hg38 take 33.9 s against 33.3.
The rolling lookup that finds the match runs whatever the PAM says, and
with a library of every 9-mer it succeeds nearly everywhere, so the
allocations were never the marginal cost. I expected otherwise and
measured it.

It halves the peak, 2.91 GB to 1.45, and that is what pays: batches of
5,000 now fit in 5.5 GB, which spreads the 21-second genome pass over 53
runs instead of 263 and takes the full 262,144-guide library from 2.5
hours to 1.4. Output is byte-identical, counters included.

The per-base rule moves into code_ok, which matches_pam was the only
caller of, so that goes; pam_ok_at reads it twice per match without
allocating. fits is now shared with plain_slice rather than restated,
which is what the minus-strand bounds depend on: start - pam_length
wraps to usize::MAX for a match at the very start of a contig.

Tests: a parametrised check over random genomes that the filtered scan
equals the full scan filtered and that the tallies match the oracle's own
count, plus that contig-start case. The oracle itself only ever exercises
the unfiltered path, so it would not have caught a tally drifting into its
new home.

Ran the full 9-mer library against hg38 on this build: 53 batches, 85
minutes, no failures.

🤖 Generated with Claude Code