Add MFE vendor pin file and reader

What does this MR do and why?

Adds the committed MFE version pin file and its reader — the first part of the registry-direct micro-frontend (MFE) delivery series (see below for the full picture).

• vendor/mfe.yml pins each MFE 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. The file has lockfile semantics and is seeded with the real published duo_chat 0.4.0.
• Gitlab::Mfe::VendorFile parses and validates the pins: name/semver/sha format checks, duplicate-pin rejection, and actionable InvalidEntryErrors for every malformed-input case (non-map root, non-list apps, non-map entries, unreadable or syntactically broken file). Entries are memoized and deep-frozen (structs, array, and strings) so no consumer can corrupt the shared pin data, and a no-stub smoke test guards the committed file itself against hand-editing mistakes.

Nothing is wired into any runtime or build path yet — this is dead code until the final MR of the stack lands, which is the safety guard for the whole series.

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 (this MR)
2	!249068 (closed)	Registry version manifest contract
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.