Harden release validation for tap metadata and source refs

Parent epic: #15

Depends on: #17, #18, #21

Why

A plugin release should not publish a package that cannot be represented accurately in the tap. Release validation currently checks version equality and basic PyPI metadata only. It must also validate that the generated schema v2 catalog entry is fresh, installable, and consistent with the release tag.

Concrete release contract

For a release tag data-designer-example/v0.1.0, release validation should verify:

• The plugin directory is plugins/data-designer-example.
• [project].name == "data-designer-example".
• [project].version == "0.1.0" and is valid PEP 440.
• The tag name equals [tool.ddp.tap].release-ref-template.format(package=project.name, version=project.version).
• Required PyPI metadata exists: description, license, readme, authors.
• [project].requires-python is present and valid.
• Exactly one direct versioned data-designer dependency exists.
• The current generated catalog contains at least one schema v2 entry with package.name == project.name and package.version == project.version.
• All catalog entries for the package have valid entry_point, compatibility, source, and docs fields matching #16 and #18.
• For pypi source entries, source.package == project.name.
• For git source entries, source.ref equals the release ref and source.subdirectory == package.path.
• Release validation fails if the package's catalog source is path.
• docs.url equals {docs-base-url.rstrip('/')}/plugins/{docs_slug}/.

CODEOWNERS release authorization contract

Use GitHub identities for release authorization:

• Per-plugin CODEOWNERS may contain GitHub users, GitHub teams, or emails for review ownership.
• A releasable plugin must include at least one GitHub user (@user) or team (@org/team) owner.
• Email-only ownership should fail ddp check-release with a message asking for a GitHub owner because publish CI cannot reliably authorize tag pushers by email alone.
• Local make release and publish CI should use the same owner parsing helper.

Implementation

• Extend devtools/ddp/src/ddp/validate_release.py with the checks above.
• Add reusable helpers for release tag parsing, catalog entry lookup, and CODEOWNERS owner parsing.
• Update publish CI to call the strengthened validation before build/publish.
• Add tests for valid single-entry packages, valid multi-entry packages, stale catalog entries, missing docs/source, mismatched ref, path source on release, and email-only CODEOWNERS.

Acceptance criteria

• make validate-release PLUGIN=data-designer-example fails if catalog v2 output is stale or incomplete for that package.
• Release validation catches mismatched package version, tag/ref, source metadata, and docs URL metadata.
• Multi-plugin packages validate every entry point for the releasing package.
• Email-only CODEOWNERS cannot pass release validation.
• Local release checks and publish CI share the same validation behavior.
• Tests cover the failure modes listed above.

Dependencies

• Depends on: #17, #18, #21.
• Blocks: reliable PyPI/Git tap consumption and #25 release workflow docs.

Start in devtools/ddp/src/ddp/validate_release.py and trace the existing release checks and publish CI invocation. Add reusable tag, catalog, and CODEOWNERS parsing helpers, then add coverage for the listed valid and failure cases; done means local and CI validation enforce the full release contract.