PLUGIN.md: record the real bundler build as verification

generatePluginsModule + rebuildFrontend, called directly with a synthetic install state, exercises
the same Bun.build + Tailwind path a real install performs — no server running, no port bound. It
compiled cleanly: 3 outputs, 2.2s, zero errors. Stronger than tsgo alone (catches bundler-side module
resolution and JSX/CSS processing), but does not confirm the result renders correctly in a browser —
noted as still open.

PLUGIN.md

@@ -146,6 +146,15 @@ expected, not a bug.
   unknown route answered the OpenAI-shaped `404` envelope. Old provider rows correctly failed to
   decrypt (a fresh `secret.key` was generated for this checkout, as intended — a key that will not
   decrypt is broken, not absent, and `keyForProvider` reports `configured: false` rather than crashing).
+- **The real production SPA bundle builds successfully with the plugin included.** Called
+  `generatePluginsModule` and `rebuildFrontend` directly (the same functions `refreshPluginMounts` calls
+  during a real install) against a synthetic "atelier is installed and enabled" state — no server
+  running, no port bound. `Bun.build`, with the real Tailwind plugin, compiled `Plugins.gen.tsx`, all
+  three panels, and the new `AtelierProviders` settings section in 2.2s with zero errors: 3 outputs, no
+  warnings. This is the same build step an install performs and exercises everything `bunx tsgo` cannot
+  — module resolution through Bun's own bundler, JSX compilation, Tailwind processing — without needing
+  a running server. What it does not prove is that the result **renders correctly in a browser**; see
+  below.
 - **Not done**: a live PM2 install/enable/disable/uninstall/purge cycle through `/marketplace`, per the
   runbook's own verification table. This machine's live `officer` process serves the owner's real
   session and its own `plugins/` directory is the main checkout, not this worktree — installing through