[P2] Make the scaffold's default test command test the plugin; keep proof-level separation inside the harness, not in the user's command choreography

[ScriptedAlchemy]

Problem

The normal action npm test in the MCP starter excludes the route and projection tests—the parts that prove the plugin works. The author must know to run test:routes, test:projection, and a multi-stage check sequence separately. This exposes the framework's own proof-pool architecture as basic application setup.

Main reviewed: 14c9822bc6c01d8ff2788454d0e1dc7861bc3816; source-only review. No claim that the current explicit check script fails: it correctly runs the separate pools. The problem is the default user contract and unnecessary orchestration burden.

Evidence

• MCP template package_json: test runs rstest tests --exclude "tests/{route-unit,projection}/**"; check spells six sequential commands.
• MCP template README makes authors learn three pool commands before their first plugin change.
• rstest.route-unit.config.ts and rstest.projection.config.ts already delegate correctly to agentBundleRstest. Preserve that machinery instead of duplicating compiler/React setup.

Minimal direction

npm test should run the starter's normal deterministic application suite, including its route/projection tests, with separate reported proof labels. Keep focused subcommands for debugging and keep packed/native/credentialed tests explicitly opt-in or a separate integration gate. An aggregate script over existing helpers is enough initially; do not introduce another test runner or flatten incompatible module conditions.

Where the same graph can safely be reused, avoid compiling it independently solely to achieve distinct labels. Preserve isolation where React conditions, mutations or test lifecycle require it; measure before claiming a speedup.

Acceptance

• Break the example's route rendering or MCP registration while plain domain tests remain green: the documented default test command must fail.
• All promised normal test files are collected on a clean project, with no route/provider/type-generation prerequisites silently omitted.
• Output still distinguishes domain, route and protocol claims. A successful in-memory test is never labelled native-host/installed-package evidence.
• Test filtering and watch work through the supported public configuration; no handwritten aliases into framework source.
• Static skill/plain-hook templates do not gain an unnecessary React/MCP pool.
• The documentation leads with one ordinary test command, then explains optional depth when needed.

Coordinate generated-type readiness with #748. Keep existing framework CI's specialized pools; this issue is about the public plugin-author experience, not rewriting the repository's test infrastructure.

[ScriptedAlchemy]

Coordination note from the onboarding-docs side (#750/#754, #745): the authoritative pages your
change will need to update now exist and are merged, so please edit them rather than adding a
parallel description of the test story.

• website/docs/en/guide/development/troubleshooting.mdx (and its zh twin) carries the row a
  reader hits today: "A green default test did not catch a broken route — the current MCP
  starter's check includes route/projection pools, while its npm test alone excludes them.
  Use the full documented check until the script contract changes." When this issue lands, that
  row is the sentence to delete or rewrite, in both locales.
• website/docs/{en,zh}/guide/start/quick-start.mdx tells an author to run npm run check after
  adding the first tool, and the "Test the layer you changed" table in
  guide/authoring/reuse-framework.mdx maps a change to its smallest useful proof. If npm test
  becomes the command that tests the plugin, both need the new command.
• packages/create-agent-bundle/README.md documents the template scripts, and
  templates/minimal/README.md explains at length why a skills-only project ships no route pool
  — that prose is the existing statement of proof-level separation.

Two things to know about the surrounding state:

• Project creation now offers every target the compiler registers ([P2] Make scaffolding and installation guidance consume the supported host catalog; Amp is currently rejected at project creation #745, merged as
  b0b25d3b1338594d854da781fa22c71581f814fc), and the scaffolder reads one hostCatalog in
  packages/create-agent-bundle/src/options.ts held to createDefaultRegistry() by
  tests/host-catalog.test.ts. If your change alters what a template's scripts are, the same
  catalog is where a per-template fact belongs — please extend that table rather than adding a
  second one.
• The template README install lines are rewritten by rewriteReadmeInstall in
  packages/create-agent-bundle/src/scaffold.ts against drift-checked markers, so a README edit
  that touches those two blocks has to keep the markers matching or the scaffolder throws
  "Template drift".

The docs pages are held by pnpm docs:site:build (language parity fails the build if one locale
gains a paragraph the other lacks), so an en-only edit will not pass the gate.