[PATCH 07/12] lib-index: Add keyed xxh64 strmap format v2, gated by config version

[PATCH 07/12] lib-index: Add keyed xxh64 strmap format v2, gated by config version

The on-disk hash stored in the strmap file is now optionally a keyed
xxh64_to_32() with a per-file random 64-bit IV stored in the file
header.  This replaces the previous plain crc32_str_nonzero() output
and hardens the strmap against deliberately-collided message-id
hashes.  The v1 (crc32) format remains fully readable and writable
so older configurations keep working without forced rebuilds.

On-disk:
 - v1 header is 8 bytes: version, 3 unused, uid_validity (unchanged).
 - v2 header is 16 bytes: version, compat_flags, 2 unused, uid_validity,
   hash_iv.  The first 8 bytes of v2 align with v1 byte-for-byte, so
   the open path reads 8 bytes, dispatches on version, and reads the
   trailing 8 bytes only for v2.

Runtime:
 - strmap->enable_xxh64 selects the format used when creating a new
   file (or recreating one whose uid_validity has changed).
 - view->format_version follows the on-disk file when one exists; for
   fresh files it follows the strmap-wide preference.
 - Renumber recreate_write() preserves view->format_version, so we
   never silently migrate an existing file across the threshold while
   it is still in use - the migration only happens at open time.
 - When enable_xxh64 is TRUE and the on-disk file is v1, open treats
   it as a version mismatch: the file is unlinked and the next sync's
   recreate_write() produces a v2 file.  Below the threshold v1 stays
   v1 indefinitely.
 - strmap_hash_str() dispatches per-view, so v1 files keep using
   crc32 hashes and v2 files use keyed xxh64 even in mixed setups.

Gbp-Pq: Name 0007-lib-index-Add-keyed-xxh64-strmap-format-v2-gated-by-.patch