Add MFE registry version manifest contract

What does this MR do and why?

Adds the registry version manifest contract — the security-sensitive validation layer of the registry-direct micro-frontend (MFE) delivery series (see below for the full picture).

• Gitlab::Mfe::RegistryManifest + JSON schema validate a per-version registry manifest (module/version/algorithm/assets[] with per-file path/size/sha256; optional checksum/base_url/generated_at/archive kept forward-compatible).
• Defensive posture, since this parses untrusted registry bytes:
  • asset paths are traversal-rejected at schema level and re-checked in Ruby;
  • schema patterns compile with ECMA string anchors (regexp_resolver: 'ecma'), so embedded newlines cannot smuggle data past Ruby's line-anchor ^/$ semantics;
  • duplicate asset paths are rejected instead of silently collapsing to the last entry;
  • .parse is the only public entry point (.new is private), so an unvalidated manifest object cannot exist;
  • every failure mode — non-string body, empty body, malformed JSON, oversized payload, schema violation — surfaces as a single ValidationError.

Nothing consumes this class yet — dead code until the final MR of the stack lands.

The series

GitLab-hosted micro-frontend apps are pinned to exact versions and baked into release assets after byte-level verification against the MFE registry (demo registry: https://gitlab-mfe-registry-demo.storage.googleapis.com). The work is split into five small stacked MRs, merged bottom-up:

#	MR	Content
1	!249067 (merged)	Vendor pin file and reader
2	!249068 (closed)	Registry version manifest contract (this MR)
3	!249069 (closed)	Baked manifest writer/reader
4	!249070 (closed)	Verified bake orchestrator
5	!249071 (closed)	Rake task and asset-compile wiring (the integration flip)

Related to #605798 (closed) (MFE Phase 1: verified delivery foundation).

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.