sodium: incorporate the libsodium 1.0.21/1.0.22 hardenings (three items, not one)

[rowan-claude]

Clears the pending incorporation item in sodium/NOTES.md — and corrects the review that recorded it, which found one relevant change when there were three.

The earlier review read the upstream changelog. This one diffed the trees file-by-file. A summary is not a diff, and two of the three were missed.

What changed inside the vendored slice

#	change	why it matters
1	ACQUIRE_FENCE in all three AEAD decrypt paths	speculative-access hardening — plaintext must not be produced before authentication completes. Placed between the auth-failure return and the stream-xor, exactly as upstream.
2	crypto_verify_n constant-time hardening (verify.c)	not previously found. Inline-asm optimisation barrier + volatile optblocker_u16 through the final reduction. This is the function that compares the Poly1305 tag — it defends constant-time code against the compiler making it branchy, i.e. against reintroducing a timing side channel. Arguably the most security-relevant of the three.
3	poly1305 SSE2 final reduction	not previously found. Same optblocker_u64 treatment. Upstream did not change donna64, and the changed line here is confirmed inside the poly1305_state_internal__sse2 section — so only the SSE2 copy moved.

SODIUM_VERSION_STRING 1.0.20 → 1.0.22. HAVE_GCC_MEMORY_FENCES and HAVE_INLINE_ASM are derived from the compiler's own macros, the same way this amalgamation already derives HAVE_TI_MODE and the SIMD intrinsics. On MSVC ACQUIRE_FENCE falls back to (void) 0 — precisely upstream's behaviour when autoconf finds no fence primitive.

Verification, including proof the tests can fail

These are defence-in-depth: none should change ciphertext, tags or interop. So the test is a differential one, not a hand-copied vector.

• Patched vs pristine 1.0.20 baseline, both built against the same harness: byte-identical output across 829 lines — 200 randomised encrypt / decrypt / tamper-reject rounds for both AEADs, plus the crypto_verify_* contract. No observable behaviour changed.
• Proven capable of failing: injecting the single most plausible transcription error in this patch (>> 3 for >> 2 in the optblocker reduction) made the harness reject valid ciphertext and exit 1 at the first iteration.
• Full bin/test suite passes.

The documentation defect underneath

NOTES.md told the reader to re-run test_crypto_aead_vectors as the primary validation. That test did not exist in this repo — it lives in yojimbo, and these notes had been copied across (they still said "so yojimbo has no external libsodium dependency"). A documented validation path that cannot be followed is the same failure as no validation at all.

So this PR adds test_crypto_aead_vectors to netcode.c, registered first in netcode_test(): golden ciphertext for both AEADs, the tamper-rejection path, and the crypto_verify_* contract. Proven to fail — flipping one byte of the golden turns it red, and reverting turns it green.

It is declared static deliberately: yojimbo vendors netcode.c and compiles it with NETCODE_ENABLE_TESTS=1 while defining its own non-static test_crypto_aead_vectors in test.cpp. Internal linkage keeps the two from colliding on the next re-vendor.

Deliberately not applied

The remaining 1.0.20 → 1.0.22 deltas inside the slice are cosmetic and are now enumerated in NOTES.md rather than left unknown: /* LCOV_EXCL_LINE */ coverage annotations, defined _AIX → defined(_AIX), and an unused uint32_t t32 removal. None affects generated code.

Follow-up

yojimbo vendors sodium/ and netcode.c from here, and its copy is currently blob-identical. Once this lands, yojimbo needs a re-vendor to pick up the hardenings — base libraries first, green, then yojimbo.