[P2 docs] Refresh compiler-architecture target registry and capability evidence for Amp

[ScriptedAlchemy]

Documentation drift

Audited docsite against main 14c9822bc6c01d8ff2788454d0e1dc7861bc3816 while expanding #754.

website/docs/{en,zh}/guide/concepts/architecture.mdx still describes the pre-Amp target registry:

• its built-in adapter table lists only claude, codex, cursor, and portable;
• the prose says createDefaultRegistry registers portable, then codex, claude, and cursor;
• it therefore omits the current amp adapter and its pinned amp-0.0.0-20260907001852-gf348fed.json capability evidence.

Current production registry/tests include Amp as a built-in target. The convention-first/capability pages in #754 already present all five targets correctly, so the architecture page should not contradict them.

Required correction

Update both locales together:

• Add amp to the built-in adapter/planner table, naming adapters/amp.ts and the pinned capability JSON.
• Update the registry-order/registration prose to include Amp. Do not imply order is author-facing target precedence; target selection is normalized/sorted for composite identity.
• Explain Amp's architectural difference briefly: a generated directory PluginAPI factory under .amp/plugins/<name>/, API-registered callbacks/Skills, and skill-scoped MCP constraints. Link to the generated Hosts matrix instead of copying its detailed evidence.
• Keep portable as the default target and keep the statement that plugin is not a target.
• Link the new/updated target-capability guide from docs: complete convention-first guides, targets, and capability navigation (EN/ZH) #754 so architecture readers can leave compiler internals for the author-facing support map.
• Remove stale historical wording that implies the generated Hosts matrix has only four built-in adapters.

Acceptance

Run the docsite locale-drift/link/anchor gates and search the built site for stale statements equivalent to “portable, codex, claude, and cursor” where the text is claiming the complete built-in registry. The generated hosts.md/events.md/notices.md remain authoritative for detailed capability states; do not hand-copy those matrices into architecture.

This is documentation only. It does not request another adapter, target registry, capability system, or changes to Amp runtime behavior.

[ScriptedAlchemy]

Closed by #758, squash-merged as 0ef0436ef79737485b9f8698d246edc5c6fb115a.

Ask	Where it landed
amp in the built-in adapter/planner table, naming its module and pinned capability JSON	guide/concepts/architecture.mdx (en + zh): ampAdapter.plan in adapters/amp.ts, adapters/capabilities/amp-0.0.0-20260907001852-gf348fed.json
Registry prose includes Amp, without implying order is author-facing precedence	The createDefaultRegistry paragraph now ends with amp and says planComposite sorts the selection (sortedProjections) before planning, with the composite identity the sorted name join
Amp's architectural difference, briefly, linking the generated matrix rather than copying it	One paragraph: a generated index.js PluginAPI factory under .amp/plugins/{plugin}/, Skills and callbacks registered through the API, skill-scoped MCP (exactly one Amp Skill for a canonical server; a compiler-owned local server refused for want of a documented plugin-root placeholder). Links the generated Hosts page and the capability map from #754
Keep portable the default and plugin a non-target	Both sentences kept verbatim
Remove stale wording implying four built-in adapters	"Four planners, one merge" → five, including ampAdapter.plan; BundleIdentityHost corrected to amp | claude | codex | cursor with the note that DoctorHost excludes Amp

Acceptance: pnpm docs:site:build green (locale drift, diagnostics coverage, language parity,
0 broken links over 30105 anchors), plus pnpm build, pnpm typecheck, pnpm lint, and
pnpm test:unit (4480 tests, 0 failures). The built site was searched for stale
"complete built-in registry" enumerations; the only remaining four-host list is the host-scoped
config keys in reference/configuration.mdx, which is correct — the Amp adapter declares no
configExtension.

Review caught one real error in the first draft: the composite-root paragraph had been extended
to claim Amp reads the artifact directory as its plugin root and shares skills/, hooks/,
mcp/, scripts/, bin/, and INSTALL.md. Amp's root is the nested .amp/plugins/<plugin>/
directory, self-contained down to its own skills/ and hooks/, and install amp copies only
that subdirectory. The merged text states the exception.