Add MFE vendor pin file and verified bake task

What does this MR do and why?

Part 2 of the registry-direct MFE series: the vendor pin file and the verified bake task that turns pins into static release assets, working against the real registry contract (demo: https://gitlab-mfe-registry-demo.storage.googleapis.com).

• vendor/mfe.yml pins each app as {name, version, sha} where sha is the SHA256 of the app's registry version manifest ({registry_url}/{name}/{version}/manifest.json) — the same value the registry app index publishes as versions[].checksum. Seeded with the real published duo_chat 0.4.0.
• Gitlab::Mfe::RegistryManifest + JSON schema validate the version manifest (module/version/algorithm/assets[] with per-file path/size/sha256; optional checksum/base_url/generated_at/archive, forward-compatible); asset paths are traversal-rejected at schema level and re-checked in Ruby.
• Gitlab::Mfe::Baker (rake gitlab:mfe:bake) fetches the manifest via Gitlab::HTTP, verifies the pinned sha over the raw bytes, then downloads the version's assets.zip in a single request, verifies the archive bytes against the manifest's declared sha256, and extracts with zip-slip and decompression-budget guards — re-verifying every file's declared size and sha256 in memory before atomically writing public/assets/mfe/{app}/{version}/** and baked-manifest.json ({apps: {name: {version, manifest_sha256, mf_manifest_path}}}). One corrupted byte aborts the whole bake with nothing written. (Live: 211-file duo_chat bake in ~1.1s vs ~103s per-file.)
• Pinned-origin policy: asset URLs are always constructed from the configured registry_url; manifest-supplied base_url and archive.url are ignored.
• Wired into gitlab:assets:compile, but skips unless mfe is enabled in gitlab.yml — default asset builds stay network-free. No DB access on this path.

Verified against the live demo registry: a full bake of duo_chat 0.4.0 (211 assets, 3.3 MB, including its mf-manifest.json) completes with every hash checked.

Forward-compatibility note: a GitLab compatibility range is planned to land in the registry app index later (proposed: gitlab: "<= MAJOR.MINOR" per versions[] entry); readers here ignore unknown fields by design.

How to verify

bin/rspec spec/lib/gitlab/mfe/ spec/tasks/gitlab/mfe_rake_spec.rb spec/lib/gitlab/mfe_spec.rb

Stack

#	Scope	MR
1	Config section + instance kill switch	!246732 (merged)
2	Vendor pin file + registry manifest schema + verified bake task	this MR
3	Version overrides table + resolver	!246753 (closed)
4	Admin API + routes + sidebar	!246758 (closed)
5	Admin UI (Vue)	!246764 (closed)
6a	Runtime loader: gon contract, manifest verification + SRI, baked fallback, CSP connect-src	!246775 (closed)
6b	Duo Chat consumer behind mfe_duo_chat	!246778 (closed)
7	Developer mode (local dev server + HMR)	!246833 (closed)

Related

• Phase 1 issue: #605798
• Epic: gitlab-org#22777

Related to #605798.