docs(conventions): ContentType, the ToS registries and SeedID re-case names that registry-protocol.rst says keep the registrar's casing #2565

From the 2026-11-01 conventions audit, re-verified on 73add05a3. registry-protocol.rst, "RFC-Directed Case Sensitivity" and the int-tier paragraph: a member name "preserves the registrar's casing exactly", and a registry's spelling is never quietly normalised. These crawlers re-case:

• pcapkit/vendor/tls/content_type.py ContentType.clean_name lower-cases, so IANA's ACK (26) is ContentType.ack. Its docstring gives the basis (RFC 9147 §4.1 writes ack); the page has no entry for it.
• pcapkit/vendor/ipv4/tos_del.py, tos_thr.py, tos_rel.py and pcapkit/vendor/ipv6/seed_id.py call self.rename(...).upper(): the hand-typed DATA labels 'Normal', 'High', 'Low' become NORMAL, HIGH, LOW, and 'IPv6 Source Address' becomes IPV6_SOURCE_ADDRESS. The sibling tos_pre.py keeps its casing (Network_Control).
• Probe: git grep -n "\.upper()" -- pcapkit/vendor/ipv4/tos_thr.py pcapkit/vendor/ipv6/seed_id.py.

Fix: record each as an exception on the page with its basis: ContentType, RFC 9147 §4.1; the ToS and SeedID labels come from the crawler's own DATA, so they are the project's spelling, not a registrar CSV's. A rename is observable to callers, so this is a page edit.
Blocked: #2521 edits registry-protocol.rst; unblocks when it merges (gh pr view 2521 --json state -q .state prints MERGED).