fix: the 2026-10-12 dry-run reds (GCC 11 sha256, fuzz link, cypher leak, memwaste budget)

[DeusData]

The 2026-10-12 dry run (run 38186491924, main 475db1e) was red on four causes. This PR fixes three of them, plus a Cypher parser leak the fuzz job found as soon as it could build. The fourth cause, a doc_mentions_go hang on windows-11-arm, did not reproduce locally (0 hangs in 32 runs on a Windows arm64 VM) and is not touched here; the dry run on this branch is its second CI sample.

dry-run job	cause	fix
test-unix ubuntu-22.04-arm, all 3 shards	src/foundation/sha256.c (#2441) did not compile with GCC 11: its ARMv8 path was marked target("+sha2"), but GCC 11's arm_neon.h declares the SHA2 intrinsics under +nothing+crypto, so they could not be inlined. PR CI builds only with GCC 13 (ubuntu-24.04-arm); ubuntu-22.04-arm runs only in the dry run and the release.	GCC gets target("+crypto"), which implies +sha2 on every GCC. clang keeps sha2.
fuzz	the fuzz binary links through the C driver, which on Linux leaves out UBSan's C++ runtime; the C++ objects' -fsanitize=vptr checks need it (__ubsan_vptr_type_cache). The job has never built in CI since it was added on 09-18.	-fsanitize-link-c++-runtime on the link line.
fuzz, once it links	the cypher target leaks on a checked-in seed, MATCH p = (a:Class)-[:INHERITS*1..3]->(b:Class) … (288 bytes, 2 allocations). parse_match_pattern returned on a parse error without freeing the pattern it had started, and callers count a pattern only after it parsed. Every named path (p = (...), not supported) leaked, as did the failed element's own allocations and parse_props' already-parsed entries.	free and zero the partial pattern on every failure (counting the failed element, which parse_node / parse_rel zero first); parse_props frees its parsed entries through one helper. New test cypher_parse_error_frees_partial_pattern covers five failure points.
memwaste / event-macos	scripts/memwaste.sh set no budget, so the daemon derived one from the runner's RAM: 1792 MB on the 7 GB macos-14 runner, about 4 GB on the 16 GB Linux and Windows runners. The event layer itself holds 0.5-1 GB, and the index stopped with over_memory_budget before measuring anything (10-04 and 10-12).	memwaste.sh passes one explicit CBM_MEM_BUDGET_MB=4096, what the larger runners already derived, unless the caller sets one.

Checks

• sha256, arm64 containers:
  • sha256.c with CI's ASan/UBSan flags compiles on GCC 11, 12, 13 and 14; on GCC 11 the old +sha2 fails with the CI errors.
  • A known-answer harness ("abc", "", a 1 MiB pattern) matches Python's hashlib on the arm-sha2 backend and on the forced portable backend, with GCC 11 and 14 at -O0 and -O2.
• fuzz, ubuntu:24.04 container with CI's packages (clang 18, llvm, libclang-rt-dev):
  • minimal reproduction (a C++ virtual call under -fsanitize=undefined, linked through clang): without the flag, CI's two undefined symbols; with it, it links and runs. macOS Homebrew clang accepts the flag under -Werror.
  • the real make fuzz links. One deviation: lsp_all.o was compiled with -g0 added, because the 12.5 GB container ran out of memory compiling it with full debug info (CI's runner gets past it).
  • the CI smoke, scripts/fuzz.sh all --runs 20000 --seed 1: first the cypher leak above. With the Cypher fix, extract, cypher and config each complete 20000 runs.
• cypher leak, the fuzz binary on five failing queries: before the fix the first four leak (288-348 bytes, LSan rc 77); after it all five are clean. macOS: the cypher suite passes, 217 tests, including the new one.
• Lint on the changed C files: Homebrew clang-format and CI's cppcheck 2.20 are clean.
• memwaste, this Mac with CBM_WORKERS=3 (the macos-14 runner's core count):
  • budget 1792: over_memory_budget in parallel_extract (RSS 3904 MB), the CI failure;
  • budget 4096: the index completes and the report is written;
  • the edited script with no budget in the environment applies 4096 and exits 0.

The target gate is the dry run dispatched on this branch.