chore(libs): nistcurves v0.9.1 -> v0.10.1, x25519 v0.10.0 -> v0.11.0 (lib-contract phase-3 wave)

[JC-000]

Closes#112.

submodule	was	now
libs/nistcurves	v0.9.1 f9701e1	v0.10.11edd634
libs/x25519	v0.10.0 68ae0ef	v0.11.0e9af04e

v0.10.0 of nistcurves was skipped as the issue instructs — it ships content
self-reporting as 0.10.1 and is documented-as-superseded.

Both REU-profile PRGs are byte-identical across the bump. For the shipped
default this is a pure export-surface change. Getting there needed four
consumer-side migrations, and one of them fails silently.

---

The four migrations

1. -D zp_ptr2=$3d → -D nistcurves_zp_ptr2=$3d
(tools/integration/build_nistcurves_p256.sh)

The §6.5 window made the four general-purpose scratch slots canonically
nistcurves_zp_{tmp1,tmp2,ptr1,ptr2} and kept the bare names as aliases — but
the alias assignment is not .ifndef-guarded:

.ifndef nistcurves_zp_ptr2 nistcurves_zp_ptr2 =$fd.endifzp_ptr2 = nistcurves_zp_ptr2 ; <- not guarded

so the old spelling stopped being an override and became
zp_config.s(56): Error: Symbol 'zp_ptr2' is already defined. Loud, for once —
this class of mistake is normally runtime memory corruption several layers from
its cause. The od65 post-check was retargeted to the canonical name, because the
bare one disappears under -D LIB_NO_BARE_EXPORTS=1 and a guard that can go
vacuous under a build-tightening flag is worse than no guard.

2. LIB_ABI_VERSION 1 → 2 (src/lib_contract_asserts.s)

The assert fired as designed. The re-check it demands is now written into the
file so the next person can audit the audit instead of repeating it. Method:
git diff v0.9.1 v0.10.1 -- src/ filtered to export lines, intersected with
every import of c64-https's own objects (od65 over build/*.o,
build/crypto/**, build/net/**, excluding build/lib staging).

Removed unconditionally: LIB_SHARED_REU_MUL_{BANK,OFFSET,BANKS_USED} — the
three unprefixed §8.2 consumer-input equates. c64-https imports zero of
them, and could not usefully have: every §8.2 consumer defines the same three,
which is exactly why exporting them produced Duplicate external identifier in
any two-library link. Everything else in the wave is additive at the default
gate. The surface we actually consume is unchanged at four symbols: ec_base_x,
ec_gx256, ec_scalar_mul_var, ecdsa_verify_256.

3. Four §6.5 canonical aliases (src/crypto/shared/mul_tables.s)

The library's objects now reference nistcurves_mul_{dma_lo,dma_hi,cached_a,src2_buf}.
Upstream keeps the bare spellings as aliases insidedata_shared.o — which is
precisely the member our wrapper drops, because c64-https owns those buffers.
Without the aliases:

Unresolved external 'nistcurves_mul_cached_a' referenced in:
src/fp256.s(188) ... (likewise _dma_hi, _dma_lo, _src2_buf)

They live in mul_tables.s rather than beside a definition, because src/data.s
declares the buffers only under .ifndef USE_X25519_SIBLING and the sibling's
data module declares them otherwise — importing the bare name binds to whichever
provider the link selected, with no duplication and no gating.

4. poly_prod_lo/hi ownership flip under USE_NISTCURVES_ONCHIP — the one
that fails silently

Upstream moved those two bytes outside the SHARED_CT_MUL_8X8 gate
(contract v0.9.1 adopter-private-buffer rule: fp_sqr's diagonal path writes
them with no ct_mul_8x8 involved). The wrapper's glue TU could no longer
.import them:

mul_8x8.s(223): Error: Symbol 'poly_prod_lo' is already an import

The obvious fix — delete the import — links cleanly and produces wrong
crypto.og_common does jsr ct_mul_8x8, which under SHARED_CT_MUL_8X8
resolves to our body in poly1305.s, and then reads the product back out of
poly_prod_lo/hi. Writer and reader must address the same two bytes. With two
disjoint pairs, og_common reads two zeros for every product and every
on-chip-generated multiply row is wrong, with no diagnostic anywhere. So
poly1305.s now imports the sibling's pair under that profile instead of
defining its own.

Guarded behaviourally: test_ecdsa_kat_oracle.pyon an onchip build is what
catches it. A REU build does not link mul_8x8_onchip.o at all and passes
regardless — that asymmetry is now recorded in CLAUDE.md.

§8.0 masks re-derived, not carried forward

od65 on the built archives, per profile:

profile	SHARED_PRIMITIVES	SHARED_CONSUMES	REU_BANKS_USED
REU (lib_manifest_p256verify.o)	$0007	$0007	passes & $C0 = 0
onchip (lib_manifest_p256verify_onchip.o)	$0005	$0005	$0000

Both unchanged from v0.9.1, so no assert edit was needed there. No footprint or
RESIDENT_BYTES constant is asserted in this repo, so the issue's per-archive
caveat had nothing to bite.

---

USE_X25519_SIBLING=1 links under UCI now

README.md and CLAUDE.md both documented this as failing on both backends
with ld65: Error: Duplicate external identifier: 'reu_mul_tables_init'.
Reproduced at the old pins first, then diagnosed:

Both libraries ship a SPEC §8.2 reu_mul provider. Under the sibling flag
src/boot.simportsreu_mul_init (the sibling owns the table), ld65 pulls
nistcurves' reu_mul_init.o to satisfy it because nistcurves-p256.a precedes
x25519.a on the link line, and then the sibling's provider arrives anyway via
reu_clear_wide. Note the near miss: had ld65 resolved rather than errored,
reu_mul_init would have bound to nistcurves' table builder rather than the
sibling's — a different routine writing through a different buffer set.

c64-https is the §8.0 APP_OWNED case for that primitive, so the fix is one
line: drop reu_mul_init.o alongside the mul_8x8.o / data_shared.o drops
already in the wrapper. That is the archive-surgery spelling of
-D SHARED_REU_MUL_INIT, which the wrapper cannot pass because upstream builds
every module with one recipe.

make clean && make BACKEND=uci USE_X25519_SIBLING=1 62,977 B 86889422...
make clean && make USE_X25519_SIBLING=1 # ip65
Segment 'X25519_RODATA' overflows memory area 'CRYPTO_OVERLAY' by 3584 bytes

ip65's failure has moved from a symbol collision to a fit problem: its
overlay slot is 4,212 B against UCI's 7,680 B. That is a cfg restructure, not a
flag.

Proven inert for what ships: both REU PRGs are byte-identical with and without
the drop. The flag stays OFF by default — flipping it is a separate decision
that wants a hardware handshake behind it. README.md and CLAUDE.md are corrected.

tools/test_x25519.py could not run against a sibling build at all

It aborted at FATAL: 'fe_copy' label not found before launching VICE: its nine
fe_* groups drive in-treesrc/crypto/fe25519.s internals, which a sibling
link does not contain. So the sibling had zero runnable coverage — a bad thing to
discover only after deciding to flip a default.

The fe_* requirement is now conditional on the routine family being present.
Detection is by total absence of the family, never one probe label, and
partial presence hard-fails rather than guessing — silently downgrading to two
vectors is how a broken link passes as a green run. (fe_src1/2/dst are ZP
equates present in every link and are excluded from the probe set for that
reason.) The verdict distinguishes the two possible skips, since --fast drops
the only end-to-end coverage while a sibling build keeps it.

The sibling passes both RFC 7748 vectors, including vector 2 — peer u with
bit 255 set, the vector that catches upstream #64.

-D LIB_NO_BARE_EXPORTS=1 (SPEC §6.5) — evaluated, not adopted

Measured rather than argued:

• It does not touch the symbol that actually collided.
  reu_mul_tables_init is a §8.2 canonical entry point, not a bare manifest
  equate; it is gated by SHARED_REU_MUL_INIT alone.
• Adopting it would break the onchip profile: mul_8x8.s:64 gates the
  sqtab_lo/sqtab_hi exports behind it, and src/crypto/poly1305.s:14
  imports both. It would also force the ABI import to the prefixed name.

Cost real, benefit zero at this pin. Recorded rather than done.

CONTRACT_DEFINES / CONTRACT_ZP_DEFINES

The risk the issue names is absent here: we do not patch library makefiles.
The wrapper rebuilds zp_config_*.o post-hoc with the overrides and od65-verifies
the emitted values.

v0.10.x's CONTRACT_ZP_DEFINES does now reach the per-variant zp_config rules
(libs/nistcurves/Makefile:296), and would let the rebuild + member-discovery +
variant-gate case block collapse to one make flag. Deliberately not folded in
here: it replaces the mechanism on the highest-consequence path in the wrapper,
the current one is measured-good, and this PR already carries four migrations.
Worth a follow-up issue.

---

Evidence

All at these pins, make clean between every one.

$ make clean && make # ip65
d522e68469b8fc09709f34e64fd5573a0a72465349374a26257194bd5ed96cca 47105
$ make clean && make BACKEND=uci
66e37037deb9b295d3594a50b2bacfe95d09bb7e62f3dfc401c51b03c2461fed 62977
$ make clean && make USE_NISTCURVES_ONCHIP=1
b181ec0862c2680e1ac59717a4e474d31c04d7f885d01c13f8304e7762e742a6 47105
$ make clean && make BACKEND=uci USE_NISTCURVES_ONCHIP=1
118241e975563a26d9ca69a8bc8607d7d0ec2ae259fa7f7d3e1744c0b6f13df9 62977
$ make clean && make BACKEND=uci USE_NISTCURVES_ONCHIP_COMB=1
211ad1bd841b65f473d5cbf18860c4097f14254a51ed3edb465372df202a075d 62977

PRG hashes, old pins vs new

build	bytes	v0.9.1 / v0.10.0	v0.10.1 / v0.11.0
ip65 REU	47,105	d522e684…	d522e684…	identical
uci REU	62,977	66e37037…	66e37037…	identical
ip65 onchip	47,105	13268587…	b181ec08…	moved
uci onchip	62,977	518ee446…	118241e9…	moved
uci onchip+comb	62,977	29828653…	211ad1bd…	moved

Old-pin figures were measured in this worktree by reverting the submodules and
stashing the source changes, not quoted from memory. The onchip rows move only
because migration 4 relocated two bytes out of CRYPTO_BSS. The released
v0.2.0 artifacts were built at the old pins, so those PRG hashes are superseded
— whether to cut a follow-up release is the supervisor's call, not mine.

Tests

$ python3 tools/test_ecdsa_kat_oracle.py # UCI REU
Passed: 6/6 [+] ALL 6 VECTORS PASSED (3 valid accepted, 3 invalid rejected)
$ python3 tools/test_ecdsa_kat_oracle.py # UCI ONCHIP — migration 4
Passed: 6/6 [+] ALL 6 VECTORS PASSED (3 valid accepted, 3 invalid rejected)
$ python3 tools/test_x509.py
Passed: 11/11 [+] X.509/ECDSA: ALL 11 TESTS PASSED
$ python3 tools/test_x25519.py # UCI REU, in-tree
RESULTS: 73/73 passed, 0/73 failed
$ python3 tools/test_x25519.py # UCI ONCHIP
RESULTS: 73/73 passed, 0/73 failed
$ python3 tools/test_x25519.py # UCI + USE_X25519_SIBLING=1
RESULTS: 12/12 passed, 0/12 failed -- 9 group(s) SKIPPED: fe_copy/zero/one,
fe_add, fe_sub, fe_add/sub inverse, fe_mul, fe_sqr, fe_mul_a24, fe_cswap, fe_inv

The in-tree 73/73 was re-run after the test_x25519.py edits — the default
path is unregressed and skips nothing.

Packaging

$ make package PACKAGE_PYTHON=.../.venv/bin/python3
[package] PRG matrix complete (4 variants).
[package] disk images complete. # 6 D64s
[package] wrote dist/c64-https-listener.py # 22130 bytes
[package] wrote dist/MANIFEST.txt

4/4 variants result=OK, no INCOMPLETE block, build-info.txt records
libs/nistcurves … v0.10.1 and libs/x25519 … v0.11.0 with git_dirty=no. Run
twice (once before the commit, once after); every PRG hash reproduced.

make package-verify was not run — it needs VICE boots per D64 on top of a full
rebuild, and every hash it would compare is already double-produced above.

Hardware

No hardware e2e was run. Everything above is VICE and link-time. The
U64E-side questions this bump could plausibly disturb — handshake wall-clock on
the onchip profile, and whether the sibling build completes a real handshake —
are both open and both want the device.