cpp-safety: safe-C++ playbook, fix a second UB, and a sanitizer net

Response to incident WA-2026-10-27 (the std::vector max_size() crash). Deep
research archived under research/safe-cpp-practices (8 Tier 1, 37 Tier 2, 2
conclusions) on production-safe C++ that keeps development speed: OpenSSF
compiler hardening, the C++ Core Guidelines bounds profile, integer-overflow
practice, libFuzzer/sanitizer CI, the sanitizer overhead ladder, clang-tidy
ratchets.

The research prescribed an ASan+UBSan+_GLIBCXX_ASSERTIONS build of the parsers.
Standing it up immediately caught a second, independent undefined-behavior bug
that two manual reviews had missed: a protobuf varint loop that shifted by up
to 70 bits (shift >= 64 is UB) on malformed input. Fixed and guarded by a
deterministic test and the sanitizer net.

- src/whatsapp/wa_proto.cpp: guard the wire-0 varint shift (the UB).
- tests/whatsapp_test.cpp: add an overlong-varint hostile case.
- tools/san-whatsapp.sh: the standing sanitizer net for detz::wa parsers.
- WaClient frame capture: a frame that fails to decode/dispatch has its exact
  bytes recorded to <home>/whatsapp/last-error.log (bounded), so the still
  unreproduced live <iq> failure becomes a one-paste deterministic fix. Wired
  from the wizard and the whatsapp_send tool.
- docs/cpp-safety.md: the project-wide playbook and design decisions (four
  layers: overflow-safe checked-reader parsing, cheap release hardening, the
  sanitizer test net, capture). docs/whatsapp.md section 13.6 records the
  follow-up and the honest open item. AGENTS.md makes it a standing rule;
  cap.md and mcp.md inherit it for their wire parsers.

Verified: build, whatsapp_test (incl. hostile+fuzz), make lint, and
tools/san-whatsapp.sh all green; research audit PASS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

research/safe-cpp-practices/integer-overflow-size-checks.md

@@ -0,0 +1,50 @@
+# Integer overflow and allocation-size checks in C/C++
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | safe-cpp-practices |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Integer overflow and allocation-size checks in C/C++ |
+| Source URL | https://offlinemark.com/int-overflow/ |
+| Source publisher / author | offlinemark; Offensive360; Orbis AppSec |
+| Source type | blog post |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-27 |
+| Researched by | tai (agent), model: Claude Opus 4.8, on behalf of retoor |
+| Research method | web search synthesis |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The canonical guidance for size arithmetic on untrusted input: check before the operation, never after, and never let a parsed count drive allocation or pointer math before its range and an application limit are both checked.
+
+## Key findings
+
+- Addition overflow guard for size_t: test `a > SIZE_MAX - b` before computing `a + b` (exactly the `len > size - pos` form detz now uses).
+- Multiplication guard: `b != 0 && a > SIZE_MAX / b`.
+- Checking a signed result after the fact is too late: the overflow was already undefined behavior.
+- A negative value converted to an unsigned size becomes huge; validate parsed numbers before the conversion.
+- Keep the validated count next to the allocation so the allocation and the loop cannot use different counts.
+
+## Pros / strengths
+
+Precise, copy-pasteable guards; names the signed->unsigned trap that caused the crash.
+
+## Cons / limitations / caveats
+
+Blog-level sourcing, not a standard; no single authoritative citation.
+
+## Relevance to tai
+
+This is the root-cause cure. detz replaced every `pos + len > size` with `len > size - pos`, reads lengths unsigned, and range-checks before slicing or allocating.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-27 | Initial dossier created (web search synthesis). |