perf: accelerate ordered string scans with a regex byte-class prefilter

[JeanExtreme002]

Problem

Ordered string comparisons — BIGGER_THAN, SMALLER_THAN, *_OR_EXACT_VALUE, and VALUE_BETWEEN — had no C-level shortcut. Unlike the EXACT_VALUE path (which uses bytes.find), they fell into the pure-Python fallback in scan_memory, stepping every byte (step = 1 for strings) and decoding a window with int.from_bytes per offset.

Over a real process's address space that's ~1 billion Python iterations, so a single search_by_value_between(str, …) took minutes. In the test suite, test_search_by_string_between alone was ~300s and gated the whole macOS run (xdist --dist=loadfile pins test_editor.py to one worker).

Fix

Strings compare big-endian, so a fixed-width window can only satisfy an ordered comparison when its first byte lies in a known range. The fast path:

1. Builds a regex byte class [lo-hi] for the candidate first bytes and locates them with re.finditer — whose C engine skips the long NUL runs of reserved/zeroed memory, exactly like bytes.find does for EXACT.
2. Accepts a candidate outright when its first byte is strictly inside the bound (the order is already decided), decoding the full window only on the rare boundary tie.

NOT_EXACT_VALUE / NOT_VALUE_BETWEEN keep the byte-by-byte loop (their match set is dense, so a prefilter wouldn't help), and numerics with unusual sizes (3/6/7 bytes, little-endian) are untouched.

Results

scenario	before	after
sparse 150 MB (mostly-NUL, realistic)	22.4 s	0.71 s	31x
dense 40 MB, full-range (matches every byte)	7.3 s	5.9 s	1.24x — no regression
test_search_by_string_between	~300 s	~13 s	~24x

Even the pathological full-range case is faster, because the "accept outright" path skips the per-window int.from_bytes the old loop always paid — so no density guard is needed.

Correctness review

The first-byte-dominance shortcut is only valid under two preconditions, both verified:

• Equal width. value_to_bytes builds a ctypes buffer of exactly bufflength bytes and NUL-pads, so the target reaching scan_memory is always exactly target_value_size wide (searching "AB" with bufflength=20 → b"AB" + b"\x00"*18). With equal width, a strictly-greater/smaller first byte determines the full comparison — no false positives or negatives.
• lo <= hi. A reversed VALUE_BETWEEN (start > end) would compile to a [hi-lo] class and raise re.error: bad character range. The byte-by-byte loop returns [] for start > end, so the fast path now guards lo_byte > hi_byte and returns empty to match. (Caught during review; covered by a regression test.)
• Compiled with no flags — in particular never re.IGNORECASE, which folds ASCII case inside a class and would over-match a range overlapping A-Z/a-z. Documented inline so it isn't introduced later.

Output is byte-for-byte identical to the previous loop:

• Verified against a byte-by-byte reference over 20k randomized cases (sizes 1–20, empty buffers, 0x00/0xff extremes, boundary ties, reversed ranges, and regex-special bytes [ ] ^ - \ & ~ |), with FutureWarning treated as an error.
• re.escape confirmed to yield an exact inclusive ordinal class for all 256 byte values.
• New deterministic tests in test_scan.py (incl. reversed-range and regex-special bounds) + hypothesis property tests in test_scan_properties.py.

References consulted: Python re docs (bytes patterns are matched by ordinal and are locale-independent without re.LOCALE; IGNORECASE ASCII-folds inside classes; DOTALL/MULTILINE don't affect class membership), CPython issue #74534 / bpo-30349 (the nested-set FutureWarning — not scheduled to become an error, and avoided entirely by escaping endpoints).

348 passed, 13 skipped; flake8 and mypy clean. Independent of the dyld-shared-cache fix (#50) — different files, composes cleanly.