docs: add incremental-adoption recipe page

[janechu]

Why

WebUI's existing integration recipes (Rust, Node, FAST 3.x) describe the destination of an adoption: webui build producing protocol.bin, the fast-v3 plugin emitting Declarative Shadow DOM with hydration markers, and the client using declarativeTemplate() + observerMap() + enableHydration() to bind to pre-rendered content.

That is rarely the starting point for an existing host. A team that wants to introduce a single FAST 3.x custom element into an established SSR stream typically needs to land code before the build pipeline, handler wiring, and routing are in place, so each piece can be reviewed and deployed independently.

There is currently no page that walks an adopter through a phased, reversible path. They have to infer it from the full-page recipes plus the Embedded fragments recipe (#299), the plugin docs, and the fast-element documentation, and figure out where the natural rollback boundaries are.

What

Adds docs/guide/integrations/incremental-adoption.md, a focused recipe page organised as three PR-sized steps:

• Phase 0 - ship the element with a data-state attribute bootstrap. No webui build, no protocol.bin, no handler. The element decodes its initial state in connectedCallback and renders via an imperative html template + @customElement. Goal: get the FAST class loaded behind a kill switch while SSR is wired up separately.
• Phase 1 - add SSR with the fast-v3 plugin. Introduces a thin wrapper template that names the element as a fragment entry (per the embedded fragments recipe), wires webui build --plugin fast-v3, and switches the client to declarativeTemplate() + enableHydration(). The Phase 0 fallback stays in the file gated by shadowRoot === null so the kill switch can roll back instantly.
• Phase 2 - remove the Phase 0 fallback. Drop the imperative template, the @customElement decorator, and the data-state decoding path. The <f-template> block becomes the single source of truth.

The page also calls out two valid earlier exits (Phase 0 as end state for JS-heavy SPAs that never need first-paint content; Phase 1 as end state when legacy fallback must be retained indefinitely) and links to the Embedded fragments recipe for the routing and module-CSS-dedup edge cases this recipe intentionally does not cover.

Adds the page to docs/.webui-press/config.json and docs/guide/integrations/index.md so it appears in the sidebar and the integrations landing page.

Why not a separate recipes/ directory

I considered placing this under a new docs/guide/recipes/ section, but the embedded fragments recipe sets the precedent that recipe-style pages live under integrations/. Keeping that pattern means the sidebar reads as a single ordered list rather than fragmenting recipe content across two top-level sections.

Validation

• Plain Markdown; no code changes.
• No emdashes, endashes, or unescaped {{ mustaches outside fenced code blocks.
• All {{citation.x}} references appear inside fenced code blocks where VitePress will not interpret them.
• Cross-references to other docs pages use relative links matching the conventions in rust.md and fragments.md.

Related

• chore: correct rust integration docs to match published crate #295 (re-export RenderOptions from facade) - the Phase 1 Rust snippet imports RenderOptions from webui, which currently requires chore: correct rust integration docs to match published crate #295.
• docs: add embedded fragment rendering recipe page #299 (embedded fragments recipe) - Phase 1 builds on the wrapper-template pattern.
• feat: re-export hydration plugins from microsoft-webui facade #300 (re-export hydration plugins from facade) - the Phase 1 Rust snippet imports FastV3HydrationPlugin from webui, which currently requires feat: re-export hydration plugins from microsoft-webui facade #300.
• docs: warn that hydration plugins are required for interactivity #301 (warn that hydration plugins are required) - Phase 1 commits to the hydration plugin; this PR's prose assumes that warning is visible on the Plugins page.

If all of those merge before this one, the Phase 1 snippets compile as-shown against webui from the facade alone. If any do not, an adopter can substitute webui_handler::plugin::fast_v3::FastV3HydrationPlugin etc.; the recipe text still reads correctly.

[mohamedmansour]

I don't belive we should add this doc at all, every team has their own frameworks their own clicent side and we are overly complicating our documentation which will become stale as we continue