Add the visual WebMCP Workbench

[TueJon]

Summary

• add an optional, development-only Shadow DOM Workbench that agents launch without changing the target project
• compare approved manifest tools with live imperative and declarative registrations
• provide schema-driven arguments, valid and invalid example presets, structured results, bounded session history, and confirmation for every non-read-only call
• distinguish Native from Simulated evidence explicitly so portable previews never count as browser verification
• support responsive desktop, tablet, and phone layouts, keyboard use, reduced motion, dark mode, strict CSP, and Trusted Types
• provision a pinned Playwright runtime outside the target project when needed and clean up the temporary browser session on exit

Verification

• npm run check — 40/40 passing
• node tests/workbench-browser.mjs chromium firefox — desktop, tablet, 360px, dark/light, reduced-motion, simulated transport, native-shaped transport, lifecycle, contrast, focus, overflow, strict CSP, and Trusted Types passing
• headed launcher smoke under Xvfb passing
• WebKit downloaded, but no runtime result is claimed because VD-FW lacks its required GTK/GStreamer host libraries

Safety

The Workbench is never wired into a production entry or bundle. Simulated calls are visibly labeled and cannot change a manifest tool to verified.

[TueJon]

P1 — skills/webmcpify/templates/webmcp-workbench.js:108 — normalizeExpected() accepts every manifest entry with an id, while the launcher passes the complete manifest.tools array. As a result, discovered (not yet approved) and terminal rejected tools are displayed as “Expected”/“Observed + expected”; if one is still registered, the Workbench also enables it and permits execution. That crosses the repository's manifest gate: rejected tools are explicitly excluded from every later phase, and this mode promises approved/integrated tools as Expected evidence. A manifest containing {id: "denied", status: "rejected"} is enough to reproduce the false Expected row.

Closure checklist:

• Filter launcher-provided manifest tools to entries that passed the gate; exclude at least discovered and rejected.
• Apply the same status boundary when the template receives a manifest object directly, while preserving the documented explicit expectedTools subset API.
• Add coverage proving rejected/discovered entries never appear as Expected or executable, including when a same-name live registration exists.