docs: add embedded fragment rendering recipe page

[janechu]

What

New docs page: docs/guide/integrations/fragments.md. Linked from docs/guide/integrations/index.md and added to the Language Integrations sidebar in docs/.webui-press/config.json.

The page walks through the "render one named fragment from a non-WebUI host" use case for both Node and Rust, plus a "what you don't get" section that points adopters back at the full-page recipes when they outgrow embedded mode.

Why

WebUI already supports this use case via the entry option (Node render / renderStream) and RenderOptions::new(entry, request_path) plus a custom ResponseWriter (Rust). The primitives are correct - they're just not called out anywhere.

I'm integrating WebUI into an embedded host. The integration is intentionally one component (a streamed list item inside a chat-style response stream) embedded inside a much larger non-WebUI host. I went looking for "how do I render exactly one named fragment without taking over the page" and didn't find a page for it. After reading the source I confirmed the primitives are right there - this PR is the missing recipe page so the next embedded adopter doesn't have to do the same source-reading exercise.

Stylistic notes:

• Followed the docs-sync skill: no emdashes (used hyphens with spaces), no unescaped {{ outside fenced code blocks.
• Code samples use the same shapes as the rest of integrations/.
• The Rust sample uses HandlerResult<()> from chore: correct rust integration docs to match published crate #295 - if chore: correct rust integration docs to match published crate #295 doesn't land, this PR will need a follow-up to change those return types to webui_handler::Result<()>.

How I tested

I haven't run pnpm build against the docs locally - I'd appreciate a CI run to confirm the sidebar entry and links resolve correctly.

Notes

• Branch is users/janechu/add-fragment-rendering-docs-page per my host repo's agent-driven branch convention.
• Sibling of chore: correct rust integration docs to match published crate #295, chore: correct node integration docs to match published render() signature #296, chore: document WebUIHandler thread-safety #297, feat: expose @microsoft/webui/platform subpath #298. Independent of those.
• Open question for reviewers: is the embedded-adopter use case considered first-class by the WebUI team? If not, the page may need to be louder about the trade-offs, or shouldn't ship. Happy to adjust.

[mohamedmansour]

This is not how we do embedded fragments, we already support partial rendering, which is described in the docs, I Don't belive we need another doc for just this, we expose a way to get fragments.

[mohamedmansour]

We already have docs explaining how to get partial fragments

[janechu]

Thanks for the review @mohamedmansour. Closing this PR per your preference for inline updates rather than a new page.

For the record (not arguing the outcome, just making sure the rationale is captured for future readers of this thread): renderPartial and the entry-based render/renderStream path actually serve different use cases, so the existing partial-rendering docs don't fully cover what this PR was after.

• renderPartial (docs/guide/concepts/routing.md) returns a JSON object ({state, templates, inventory, path, chain, cacheTags}) consumed by the WebUI client-side router during in-app navigation. It assumes the page is already a WebUI app with the framework runtime loaded.
• render / renderStream with entry: '<fragment-id>.html' (Node) and WebUIHandler::handle + RenderOptions::new(entry, request_path) (Rust) return HTML that a non-WebUI host can splice into its own response. That's what this PR was documenting.

So the primitives for embedded fragment rendering are different from renderPartial — but you're right that they're already exposed in the existing node.md and rust.md integration pages via the entry option, and the integration page already says "Fragment ID to start rendering from." A separate recipe page is overkill given that.

That said, two small things in this PR's content are genuinely missing from the existing integration pages and would be helpful to keep:

1. entry accepts any fragment key, not just index.html — currently the existing examples only ever show 'index.html', which underdocs the API.
2. For FAST-v3, an <f-template name="my-component"> block is not itself a fragment (components map, not fragments map); to render a single component into an embedded host you need a thin wrapper HTML file. Adopters trying to pass an <f-template> block directly as entry will hit MissingFragment and have to read source to figure out why.

Will land those two clarifications inline in node.md and rust.md as a small focused follow-up PR. Linking it back here when it's open.

Closing this one.

[janechu]

Follow-up PR with the two inline clarifications is open at #308.