Review Frontend/Container.php — dead @api DI façade (from WP-10)

[michaelmeneses]

P2 — Review Frontend/Container.php (dead @api DI façade)

Spun off from WP-10 (audit finding). WP-10 deliberately did not touch this class — conservative scope, no public-surface removal. This issue is for the review/decision only.

Finding

src/Frontend/Container.php is a static façade over the Symfony ContainerBuilder (builder/compile/get/has/isCompiled + a test-only reset()), marked @api (:30). But it has zero callers anywhere in src/ or tests/ (verified by grep). The live DI path the adapter actually uses is the framework ContainerFactory, wired from Kernel/WordPressBootstrap.php (:38 docblock: "the framework ContainerFactory during init") — which never references this class. So its static $builder/$compiled state never runs.

Decision to make (pick one — do NOT just delete blindly)

• Wrong layer/namespace? Should DI composition live under Kernel/ rather than Frontend/?
• Delegate to ContainerFactory? If a static admin-hook accessor is genuinely wanted (reach the container from add_menu_page callbacks where no constructor injection exists — its own docblock rationale), make it a thin delegate to the real ContainerFactory instead of a parallel builder.
• Rename to reflect intent.
• Deprecate / re-mark @internal — it's not real public surface; drop the @api signal (non-breaking).
• Keep as a public façade if a planned consumer needs it — then add the consumer + a test.
• Remove — only as a deliberate, documented @api-scope decision (pre-1.0), with a changelog note, not as a silent cleanup.

Acceptance

• A decision is recorded (one of the above) with rationale.
• If kept: at least one real caller + test, or an explicit @internal/deprecation marker.
• If changed/removed: changelog entry + gates green.

Priority: P2 · Risk: low · Reference: WP-10 (wordpress#1).