Add MFE baked manifest writer

What does this MR do and why?

Adds the baked manifest format — the on-disk record of what the bake produced — for the registry-direct micro-frontend (MFE) delivery series (see below for the full picture).

• Gitlab::Mfe::BakedManifest reads and writes public/assets/mfe/baked-manifest.json, recording per app the verified version, the SHA256 of that version's registry manifest, and the Module Federation manifest path, so the host runtime can later discover what was baked without re-reading the registry.
• The reader is request-path safe by construction:
  • any corrupt, missing, vanished-mid-read, undecodable, or malformed-shape manifest degrades to an empty manifest instead of raising;
  • the parsed document is memoized per process and deep-frozen, so a caller mutating a returned hash raises instead of corrupting shared state; in development/test it reloads on mtime change;
  • path_for resolves baked asset paths defensively (path traversal, null bytes, and symlink escapes all resolve to nil).

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
3	!249069 (closed)	Baked manifest writer/reader (this MR)
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.