Fix canonical names for ISO 26262 and IEC 61508

[kurtseifried]

Follow-up to #179. Making ASIL and SIL findable exposed a pre-existing defect in the two parent nodes: the canonical SecID the resolver echoes back is unusable.

The symptom

Live, right now:

?secid=asil  ->  found
   secid:control/iso.org/iso-26262-—-road-vehicles:-functional-safety#asil

That name segment is the node's description, slugified — em dash, colon and all. Nobody can use it. The real identifier is secid:control/iso.org/26262#ASIL, which resolves correctly; it is the canonical form returned to the caller that is wrong.

The cause

SecID-Service derives a node's canonical name from patterns[0], and falls back to slugifying the description when patterns[0] is not a clean literal. Compare, live:

Query	patterns[0]	Canonical returned
control/iso.org/14971	(?i)^14971$	secid:control/iso.org/14971
control/iso.org/27017	(?i)^27017$	secid:control/iso.org/27017
control/iec.ch/62061	(?i)^62061$	secid:control/iec.ch/62061
control/iso.org/26262	(?i)^26262(?:-(\d+))?$	secid:control/iso.org/iso-26262-—-road-vehicles:-functional-safety
control/iec.ch/61508	(?i)^61508(-\d+)?$	secid:control/iec.ch/iec-61508-—-foundational-functional-safety-standard

The optional part-number group makes patterns[0] a regex rather than a literal, so the fallback fires.

The fix

Split the optional group into a second pattern, so patterns[0] is a clean literal and the part-number form still matches — the same convention #134 used for version aliases:

"patterns": ["(?i)^26262$", "(?i)^26262-(\\d+)$"]
"patterns": ["(?i)^61508$", "(?i)^61508-(\\d+)$"]

Matching behaviour is unchanged; verified 26262, 26262-3, 26262-11 all still match and nope does not. Neither node's urls uses a captured variable, so nothing depended on the capture group's position.

Scope

This PR fixes only the two nodes #179 made user-facing. An audit found 170 source-level nodes across the registry with a non-literal patterns[0], all returning description-slug canonicals today — concentrated in reference/cloudflare.com (25), control/iso.org (8), reference/nist.gov (7), reference/fedramp.gov (6), control/iec.ch (5). That is pre-existing and unrelated to ASIL/SIL, so it is filed separately rather than bundled here.

Validation

validate-registry-schema.py, validate-urls.py, validate-subtypes.py, check-pattern-breadth.py all pass. Two-line diff, no reformatting.

Touches registry JSON — merging auto-deploys to the live resolver.