test_tls_p384_negotiation.py's [1b] docstring describes an armed build, not the one under test #208

Summary

tools/test_tls_p384_negotiation.py's docstring says sub-test [1b]'s C=1 "comes from
ecdsa_verify_384_tls's DER parse rejecting the 48-zero-byte dummy signature". That is true
only under ENABLE_P384_VERIFY=1. In every build anyone runs, the C=1 comes from a sec
three bytes into ecdsa_verify's P-384 arm, and ecdsa_verify_384_tls is not called at all.

Evidence

ecdsa_verify is at $6C69 in BACKEND=uci USE_NISTCURVES_ONCHIP=1. First 12 bytes:

unarmed (PRG 5f9e9fb9…)   20 81 28  AD 7C B0  F0 04  38        4C 7C 6C
armed   (PRG 3c271262…)   20 81 28  AD 7C B0  F0 06  20 96 30  4C ...
                          jsr       lda       beq    SEC/JSR   jmp
                          vic_blank curve_id                   @done

Unarmed, the P-384 arm is 38 SEC / 4C 7C 6C JMP @done — three bytes, no call. Armed, it
becomes 20 96 30 JSR $3096 (ecdsa_verify_384_tls).

Corroborating, and independent of any one build: ecdsa_verify_384_tls appears in zero
Imports-list entries across all five build/c64-https.map files (ip65-onchip, uci-onchip,
uci-comb, plain ip65, plain uci), so no JSR to it exists in any shipped PRG. od65 --dump-imports build/crypto/ecdsa_verify.o does not list it either — ca65 emits no import
record for an .import nothing references, and the only reference is inside that file's
.ifdef ENABLE_P384_VERIFY.

What is and is not wrong

The contract under test is real and still holds: [1b] asserts cv_sig_scheme=1,
ecdsa_curve_id=1, dispatcher reached, C=1, and all four are true. The suite passes 2/2
and should keep passing. Only the stated mechanism is wrong, and it has been wrong since
ENABLE_P384_VERIFY defaulted off — the docstring describes the world before the gate.

Fix is a docstring edit. Suggested wording: note that the rejection comes from the sec in
ecdsa_verify's gated-off P-384 arm, and that the DER-parse path it describes is reachable
only under ENABLE_P384_VERIFY=1.

Related, no action proposed

tools/test_ecdsa_p384_kat.py exits 1 on FATAL: required artifact missing: build/labels-p384-sha384.txt — a missing artifact, not a skip — and will do so
identically whatever happens to the P-384 lane, because the P-384 overlay build has never
completed. It therefore cannot detect a regression in the lane it is named for and must
not be cited as coverage of it.

Same family as the involuntary-skip problem behind #178/#165, inverted: there a suite
skipped silently and looked like a pass; here one fails so unconditionally that its failure
carries no information either way.