Store pichashes zero-padded so that hex order is numeric order (#145)

[r0ny123]

Closes #145.

_pichash and _picblockhashes[].hash hold 64 bit values as variable-width hex strings (hex()), so pichash:<0x99 answered a plausible but wrong set and a pichash-sorted function search could not page: the search cursor compares the sort field with a range operator, which the transpiler rejected for exactly that reason. Written 16 digits wide, string order is numeric order.

What changes

• Instance flag settings.pichash_padded. Fresh instances get it at creation; it is reported through getStats() and /status. The storage reads it once per process.
• Width-aware encoding. _encodePichash(..., padded=); _encodeFunction and recalculateAllPicHashes write in the instance's width. Import goes through FunctionEntry integers, so it follows the instance too.
• Range and sort by pichash are allowed only on a padded instance (sort key mapped to _pichash); an unpadded one rejects both with a message naming the migration, instead of answering a wrong set.
• Dual-width reads while unpadded. Search conditions, isPicHash, getMatchesForPicHash and getMatchesForPicBlockHash match both encodings ($in on the indexed field), so a migration in flight misses nothing. On a padded instance the point lookups are single-value again.
• Migration python -m mcrit.migrations.migrate_pichash_padding --mode pad|verify|unpad: resumable keyset walk over functions and query_functions with positional $set per changed value, a leftover sweep for documents a still-running server wrote below the cursor, then the flag. verify counts unpadded values and exits 1 when the flag says padded but some remain (a 16-digit value is legitimate under either encoding, so only that direction is a problem). unpad rolls back.

Operationally: stop server and workers, run pad, restart. Range/sort by pichash on an unmigrated instance keep failing the same way as before, just with a clearer message; everything else behaves as it did.

Verification

• tests/testPichashPadding.py (MongoDB): fresh instance is padded; lookups by value on both shapes; a half-migrated instance misses nothing and still refuses range/sort; range conditions answer the numeric set (pichash:<0x99 is empty); a pichash-sorted function search pages forward and backward in numeric order; migration round trip, idempotent re-run, leftover detection and CLI exit codes.
• tests/testMongoSearchTranspiler.py covers both widths and the sort helpers.
• Full suite: 210 passed. ruff and ty clean.
• Live migration of the running instance follows in a comment.

[r0ny123]

Live migration of a running MongoDB 7 instance (4 samples, 1158 functions) that was created before this change:

Before (legacy shape): /status had no pichash_padded, stored _pichash widths were 16/17/18 characters (50 of 1158 short), pichash:<0x99 answered HTTP 400 "Range operators are not supported", sorting by pichash answered 400, and matching sample 1 gave a pichash aggregation of 162 own / 166 foreign functions matched, 28 self matches.

Migration: server and worker stopped, --mode verify reported pichash_padded: false, 50 unpadded pichashes and 151 documents with unpadded block hashes, no problems. --mode pad --batch 500 rewrote 192 documents in 0.13 s, swept 0, set the flag; its verify pass reported 0 unpadded values. Stack restarted on the branch.

After: /status reports pichash_padded: true, every _pichash is 18 characters, lookups by value still find the same 4 functions for a known pichash, the matching aggregation for sample 1 is identical to the one before the migration, pichash:<0x99 answers an empty set, a pichash-sorted function search walks all 1158 functions over 24 pages in exactly the numeric order of the collection, pichash:<pivot answers exactly the 99 functions numerically below the pivot, and pichash:>=0x0 paged through the whole corpus.