Issue #42 - Consistency of NSEC3PARAM and NSEC3 chain(s)

Codeberg issue: https://codeberg.org/DNS-OARC/validns/issues/42

A signed NSEC3 zone plus four variants, each corrupting exactly one rdata
field of the canonically last NSEC3 record:

    example.sec.signed            consistent chain, validates clean
    flags-mismatch.signed         opt-out flag 0 -> 1 on one NSEC3
    iterations-mismatch.signed    iterations 5 -> 6 on one NSEC3
    salt-mismatch.signed          salt 0947E8799E2A1326 -> DEADBEEF on one NSEC3
    salt-content-mismatch.signed  salt 0947E8799E2A1326 -> 0947E8799E2A1327 (same length; exercises the byte-comparison path)

Each variant must produce "inconsistent NSEC3 <field>" for the corrupted
record. Since the corruption changes signed rdata, the RRSIG over that NSEC3
also fails to verify; tests account for that error line too.

The zone deliberately has no delegations and no empty non-terminals: every
name owns records, so NSEC3 coverage expectations do not shift when the
flags variant turns on opt-out mode.

Zone signed with RSASHA256 so signatures validate on every platform
(including RHEL9 where SHA-1 is disabled by crypto policy). Signing window
is 30 days (2027-01-01 .. 2027-01-31 UTC); the fixture is anchored by -t.

Test-time used by src/t/test.pl: 1800057600 (2027-01-16 00:00 UTC,
mid-window). If regenerate.sh is changed to use a different window, update
the -t flag in test.pl accordingly.

To regenerate:

    cd src/t/issues/42-nsec3-consistency
    ./regenerate.sh
