det512 follow-ups: fix pre-existing defects carried over from det1024

The per-call-site "if len(b) == 0 { NULL } else { &b[0] }" branches
look like they should be a shared helper, but the duplication is
load-bearing: cgo enforces its pointer-passing rules against the
syntactic form of the call arguments, so an inline &b[0] is checked
against just the slice's backing array, while the same pointer
returned from a helper is resolved to its entire containing
allocation -- and panics when the caller's slice aliases a struct
that also holds Go pointers, exactly what TestPointerToPointer and
TestDet512PointerToPointer construct. Say so where the next reader
would reach for the helper.

falcon_det{1024,512}_pubkey_coeffs skipped the first byte of the key and
decoded the remaining bytes without ever looking at it, so a buffer whose
header byte is wrong (a key for a different logn, or bytes that are not a
Falcon public key at all) was unpacked as though it were valid, returning 0
and a coefficient vector that does not correspond to any det key. The
verify entry points do not have this gap: they go through falcon_verify,
which checks the header before touching the rest of the key. Check the
byte here the same way and return FALCON_ERR_FORMAT, which the header's
"non-zero error code if pubkey is invalid" contract already promises.

deterministic1024.o and deterministic512.o were in the shared OBJ list, so
every binary linked both, including test_falcon and speed, which use
neither, and each KAT driver, which uses only its own variant. Give each
test_deterministic<n> binary its own deterministic<n>.o prerequisite and
keep the generic objects in OBJ, so a binary pulls in only the variant it
exercises. The objects still have their own rules and "clean" still
removes them.

falcon_det{1024,512}_get_salt_version take no length parameter and
read the signature's second byte unconditionally, unlike the other
entry points, which validate their input's length or take a fixed-size
format. Spell out the resulting >= 2 bytes precondition so callers
handling untrusted input know to check it (as the Go binding does).

The CT-format salt-version check compares vct but its error message
printed the stale v from the earlier compressed-format check, so a
failure would report the (correct) compressed version instead of the
offending CT one.

test_inner declared its message buffer as uint8_t data[data_len], and
the KAT loop starts at data_len = 0; a zero-length variable-length
array is undefined behavior (C11 6.7.6.2p5) and trips
-fsanitize=vla-bound before the first KAT is checked. data_len is
bounded by NUM_KATS, so use a fixed-size buffer of that length.

deterministic{1024,512}.c include inner.h (and, through it, config.h
and fpr.h), but their object rules named only deterministic.h and
falcon.h, so an edit to e.g. FALCON_FPEMU in config.h left stale
deterministic objects in an incremental build. List the same headers
as the other object rules.

hash_to_point_coeffs declared its scratch space as a uint8_t array,
but Zf(hash_to_point_ct) documents that tmp[] must have 16-bit
alignment (it stores uint16_t through it). Declare the buffer as
uint16_t so the alignment holds by construction; on strict-alignment
targets the byte array was undefined behavior. No output change: the
KATs are unaffected.

FALCON_DET{1024,512}_SIG_COMPRESSED_MAXSIZE and _SIG_CT_SIZE expanded
to an unparenthesized "...-40+1", which miscomputes inside a larger
expression such as FALCON_DET512_SIG_CT_SIZE * 2. All existing uses
are value-unchanged.

Add FALCON-DET512 via a single generated template

The committed KAT arrays derive each key from a seeded PRNG, which no
other implementation can reproduce. tests/kat_tool re-exports the same
vectors with keys, public keys and messages as literal bytes, so a port
in another language needs only a signer.

  make kat         regenerate the committed files
  make check-kat   re-derive every record and compare (added to CI)
  make kat-full    write the exhaustive 512-record sets

See kat/README.md for the format.

Ensure a pure falcon.h re-implementation matches what the KATs we
generated.

Confirm that f512 won't verify f1024 signatures and vice versa

Ensure a pure falcon.h re-implementation matches what the KATs we
generated.

Confirm that f512 won't verify f1024 signatures and vice versa