The host grammar -- the negative corpus

PROVENANCE: OURS, DERIVED FROM THE ABNF (not extracted from the RFC text)

This directory is UNLIKE test/conformance/rfc3986/, whose every file is DERIVED
from the vendored RFC text by cmake/UriCorpus.cmake and re-derived by the lane
uri.harness.corpus-provenance. RFC 3986 lists no invalid URIs, so there is
nothing to extract: negative.scm is HAND-AUTHORED, derived from the collected
ABNF at test/conformance/rfc3986/rfc3986.abnf (§3.2, itself RFC-derived) and RFC
5234 Appendix B for ALPHA / DIGIT / HEXDIG. It is the sibling of
test/conformance/charset/.

It is therefore a SEPARATE provenance with a SEPARATE count: it is never averaged into the normative §5.4 / §1.1.2
figures, and it is NOT guarded by the corpus-provenance lane. Its guard is
instead:

  - every row's (component, code, offset) is cross-checked against
    (uri test host-oracle) -- an INDEPENDENT reading of the same ABNF -- by the
    lane uri.unit.host-oracle; a row inconsistent with the oracle reddens;
  - per-production coverage floors keep the set from silently shrinking; and
  - (uri host) is run over this corpus through uri-parse-validate and must
    reject every row with the recorded code and absolute offset, and over the
    positive corpora (§5.4, §1.1.2) which it must still ACCEPT.

WHAT IS HERE

  negative.scm   invalid authority inputs for userinfo / host (reg-name,
                 IPv4address, IP-literal, IPv6address) / port and dec-octet, each
                 tagged with the ABNF production it violates and the ABSOLUTE
                 offset of the offending position (the "%" for a malformed
                 pct-encoded; the opening "[" for any IP-literal-interior fault,
                 including a dec-octet range error).
                 Every input is "http://<authority>...", so the authority begins
                 at offset 7. Every offset is defended in the row's note.

TWO HOST-SPECIFIC INVARIANTS THE CORPUS PINS

  - dec-octet is REACHABLE ONLY inside a bracketed literal. A bare "999.1.1.1"
    fails IPv4address but is a valid reg-name (§3.2.2 first-match-wins), so it is
    a valid host, not an error. Both invalid-dec-octet rows are inside "[" ... "]".
  - the split visits userinfo → host → port left to right. The last two rows are
    MULTI-FAULT authorities whose earlier fault is the one reported, so a reordered
    validator reddens (row 19 is three-fault: userinfo, host AND port; row 20 is
    two-fault: host AND port).

WHAT IS NOT HERE, AND WHY

  scheme / path / query / fragment charsets belong to test/conformance/charset/.
  The project has no ABNF-driven generator or host-aware mutator; this corpus
  is hand-derived, as the charset corpus is.
