Schema: ldapSyntaxes, X- extension flags, SUP-chain syntax resolution

[joshmakestuff]

Closes #61.

What

The neutral mechanics a consumer needs to classify attribute values from a server's schema; the binary-vs-text policy stays with consumers, per the issue's non-goals.

• LdapSyntax (RFC 4512 §4.1.5): OID, DESC, X- extensions — plus NAME, which is not in the RFC grammar but is a slapd extension its own shipped pmi.schema uses. The vendored corpus caught this the moment the ldapsyntax directive started parsing, and a new differential test pins slapd's acceptance of that exact file in CI. NotHumanReadable / BinaryTransferRequired read OpenLDAP's X- extensions with the TRUE-only rule implemented once (a published 'FALSE' is not an assertion; first value is the assertion, matching the consumer parser this supersedes).
• Parsed from all three input shapes: ldapsyntax slapd.conf directives (slaptest-verified, now CI-pinned), strict LdapSyntax.Parse, and a lenient three-parameter ParseSubschema overload (failures bucket into UnparsedDefinitions with the new Syntax kind).
• FindSyntax strips {bound} before lookup — OpenLDAP publishes bounded SYNTAX references and the bound is not part of the OID's identity; one StripLengthBound implementation now serves both the SYNTAX keyword parser and the lookup.
• ResolveSyntaxOid walks the SUP chain, cycle-guarded — OpenLDAP publishes cn as SUP name with no SYNTAX, so Syntax alone leaves most of a live schema unresolved. The generator's private depth-capped twin is deleted in favor of it.
• AttributeDescription (core, beside Dn): TypeOf("cn;lang-en") → "cn", HasOption(…, "binary") (case-insensitive per RFC 4512 §2.5), and IsValid — the writer's private definition made public, with the writer now calling it. One semantic, one implementation.

The issue's bare-OID accessor checkbox needed no code: LdapAttributeType.Syntax has stripped bounds since the parser landed, pinned by an existing test.

Proven against real OpenLDAP

The captured 2.6 fixture's 33 ldapSyntaxes values parse with zero unparsed; cn resolves to Directory String through real published data; Audio/Certificate flags read correctly. The live differential test now fetches and parses ldapSyntaxes too, and the full differential suite (5 tests, including the new slaptest pin) passed in a Linux container (slapd 2.6.10) before pushing.

Review

Two adversarial review rounds (independent reviewer models; round 1's parallel fork needed one retry after returning empty output). Round 1: 9 findings — 4 accepted and fixed in 0ada36b (corpus counter now covers syntaxes so "nothing silently dropped" is honest, slaptest CI pin, multi-value flag-rule pin, 3-param null-guard tests), the rest refuted with evidence or surfaced. Round 2: 4 findings — 3 accepted and fixed in c22adf1 (both flags pinned, two overclaiming comments scoped to their evidence), 1 declined (the naive line-scan oracle is deliberately independent of the parser; its failure direction is loud, and the green corpus is the agreement witness).

Surfaced for a maintainer ruling, not fixed: RfcGrammar.IsNumericOid implements RFC 2849's ldap-oid (leading-zero arcs like 01.2 accepted), looser than RFC 4512's numericoid. Its doc comment cites both grammars, so this reads as a deliberate single shared definition; tightening it would be a cross-cutting behavior change to LDIF and schema parsing alike.

Public API changes (core: AttributeDescription; Schema: LdapSyntax, Syntaxes, FindSyntax, ResolveSyntaxOid, 3-param ParseSubschema, Syntax enum member) reviewed line-by-line and re-approved.