Drop reverse-DNS name pattern from v2.0.0 package schema (name/version are official top-level fields)

[LittleCoinCoin]

Summary

The v2.0.0 Hatch package schema enforces a reverse-DNS pattern on the name field. But the Hatch package schema describes only the _meta extension content of a server.json; name and version are top-level server.json fields owned by the official MCP server.schema.json and validated by the registry at publish time. Hatch should not re-enforce the registry name format.

The visible symptom: hatch package add / install accepts a bare local-package name (e.g. base_pkg), but hatch validate rejects it because the v2.0.0 schema's name pattern requires namespace/name. The install path never runs schema validation, so the two disagree.

Where it lives

package/v2.0.0/hatch_pkg_metadata_schema.json:

• name carries "pattern": "^[a-zA-Z0-9.-]+/[a-zA-Z0-9._-]+$" (line ~27), plus minLength/maxLength.
• name/version are not in the schema's required list.
• The object has top-level "additionalProperties": false (line ~405).

Proposed fix

Remove the reverse-DNS pattern (and the minLength/maxLength format constraints) from the name property. Keep name and version declared as permissive optional strings — do not delete the fields.

Why keep the fields:

• The flat metadata dict validated by Hatch-Validator merges the top-level name/version in, so under additionalProperties: false the schema must still permit them.
• Hatch-Validator's local-dependency resolution reads name/version from that dict to build the dependency graph, so they must remain available.

The version semver pattern is independent of the registry-name concern and may stay.

Effect

• hatch validate stops rejecting bare/local names; the install-vs-validate inconsistency dissolves with no Hatch CLI change required.
• The reverse-DNS namespace format remains enforced where it belongs — by the official MCP registry at publish time.

Acceptance criteria

• The v2.0.0 schema no longer imposes a pattern on name.
• A package whose name is a bare token (no /) validates.
• name/version remain accepted (schema stays valid under additionalProperties: false).

Notes

• Companion issue: Hatch-Validator migrates local-dependency resolution from hatch_metadata.json to server.json (independent of this change; no landing-order constraint).
• Surfaced during the server.json migration; see the originating observation report in the Hatch repo (__reports__/resume-status/01-local_dependency_validation_gaps_v0.md).

[LittleCoinCoin]

Companion issue (independent, no landing-order constraint): CrackingShells/Hatch-Validator#23 — migrates local/path-based dependency resolution from hatch_metadata.json to server.json.