landing: expose user-plugin hook for vtz build pipeline (blocks native @vertz/mdx plugin registration)

[matheuspoleza]

Context — discovered during #2947 Phase 1 (blog dogfood).

packages/cli/src/production-build/ui-build-pipeline.ts hard-codes its Bun plugin list (createVertzBuildPlugin, aotJsxStubPlugin, jsxSwapPlugin, externalizeRelativePlugin). There is no extension point for a user / workspace to register additional Bun plugins (e.g. createMdxPlugin() from @vertz/mdx). @vertz/build exposes a defineConfig().plugins for library builds; the UI app build pipeline does not.

Workaround shipped in #2947 Phase 1: landing pre-compiles every content/blog/*.mdx via compileMdx() from @vertz/mdx into a pre-rendered HTML string embedded in a generated manifest (packages/landing/scripts/compile-blog-posts.ts). Landing's package.json chains bun run build:blog before vtz dev / vtz build / typecheck. Works, but:

• Duplicates the build pipeline surface area (two build systems for one app)
• Loses HMR — editing an .mdx doesn't live-reload
• Future MDX authoring tools (e.g. Tier 4 components, MDX lint) can't hook in

Proposal.
Add a plugins?: BunPlugin[] field to vertz.config.ts (or equivalent) that the UI app build pipeline concatenates into its plugin list. Options:

1. Extend VertzConfig in packages/compiler/src/config.ts with build?: { plugins?: BunPlugin[] }.
2. Thread those plugins through buildUIOnly / createVertzBuildPlugin's caller.
3. Watch them in the dev server file-change loop so .mdx edits trigger rebuilds.

Follow-up: once this lands, flip landing's scripts/compile-blog-posts.ts to plugins: [createMdxPlugin({ shikiTheme: 'vitesse-dark' })] in vertz.config.ts and delete the pre-build shell step.

Related:

• feat(landing): blog — dogfood Vertz stack at /blog #2947 (blog) — shipping around this gap
• plans/2947-blog/phase-01-mdx-infra.md — explicit deviation note
• reviews/2947-blog/phase-01-mdx-infra.md — adversarial review flagged S2

cc: vinicius/josh for triage.