docs(conventions): write the #2441 SSL-family and #2444 dispatcher rulings onto protocol-family-grouping.rst #2563

From the 2026-11-01 conventions audit, re-verified on 73add05a3. index.rst: a ruling answered in a thread is written onto the page that covers it. protocol-family-grouping.rst has no match for SSL, TLS or DTLS, and no criterion for when a family base carries a dispatcher.

• SSL family (the owner asked on feat(application): implement TLS/SSL and DTLS record layer + handshake framing #2441 for its grouping to be saved to convention): abstract SSL with id() ('SSLv2', 'TLS', 'DTLS') over concrete SSLv2, TLS, DTLS and SSLv3. One TLS class reads every version through a dynamic alias, with id() ('TLS',); SSLv3 is the thin subclass, as InARP is to ARP. "Member Shapes", row "One parser, dynamic alias", lists only ARP.
• Dispatcher criterion: IP and IPsec define no read() (ruled on feat(application): implement TLS/SSL and DTLS record layer + handshake framing #2441); HTTP and the IGMP base do, because the version cannot be told from the registered enum value (ruled on feat(internet): add IGMPv1/IGMPv2 as concrete classes over an abstract base #2444). It is a deliberate asymmetry, and the page records only that IP and IPsec have none and HTTP has one. refactor(application)!: dispatch HTTP to HTTPv1/HTTPv2 under the RFC names (#2524) #2544 adds a paragraph on HTTP's _dispatch that names the IGMP base, so re-read it first.

Fix: add an SSL-family section and a dispatcher-criterion paragraph, each citing the issue it was settled on; where no issue holds the ruling, say so (documentation.rst, "Paraphrasing a Ruling").
Blocked: #2537, #2540, #2542 and #2544 edit this page; unblocks when all four merge (gh pr view <n> --json state -q .state prints MERGED).