Validate registry.yaml's license field against real SPDX identifiers

Start with the license property in registry-schema.json and compare it with the existing license values in registry.yaml, including GPL-2.0 and GPL-3.0. Add the curated enum described in the issue, then update docs/registry-schema.md to explain how new licenses are added through a schema PR and verify the current registry remains valid.

Problem

registry-schema.json's license field only checks shape, not membership in the actual SPDX license list:

"pattern": "^[A-Za-z0-9][A-Za-z0-9.+-]*$"

This accepts any SPDX-looking string, including typos or made-up names (e.g. Apach-2.0), as long as the characters are alphanumeric plus ., +, -. It doesn't validate that the value is a real, known SPDX license identifier.

This isn't a security issue — the pattern already restricts to a safe character set, so unlike repository (#48) there's no injection risk. It's a data-quality gap. It's also one of the original requirements in #21: "SPDX license identifiers" was listed as a field CI should validate, and today it's only shape-validated.

Options considered

• Full SPDX list as an enum (~600+ identifiers via spdx/license-list-data): most complete, but enum bloat for a registry where every plugin today uses one of three licenses, and doesn't cover license expressions (MIT OR Apache-2.0), which check-jsonschema can't validate without a small custom grammar.
• Curated enum of licenses actually relevant here (recommended): the licenses already in use (Apache-2.0, GPL-2.0, GPL-3.0) plus a handful of common OSS licenses. Keeps the same trust model the rest of the registry already has — adding a new license means a reviewed PR to the schema, not silent acceptance of an unvetted string. Smaller and easier to maintain than the full list.

One wrinkle either way: GitHub's own license detector reports our current GPL entries as GPL-2.0/GPL-3.0, which are deprecated-but-valid SPDX IDs (superseded by -only/-or-later variants). Whatever list we land on should include those as-is rather than force an unrelated migration.

Suggested next step

Add a curated enum to the license property in registry-schema.json, seeded with the licenses currently in registry.yaml, and document in docs/registry-schema.md that new licenses are added via schema PR.

Refs #21, #48.