chore: document WebUIHandler thread-safety

[janechu]

What

Three small additions stating that WebUIHandler is Send + Sync:

1. crates/webui-handler/src/lib.rs - expand the doc comment on WebUIHandler with a "Thread safety" section explaining why it's Send + Sync and the Arc<WebUIHandler> pattern.
2. docs/guide/integrations/rust.md - new "Thread safety" section showing the same Arc example, so adopters following the integration page don't have to read the rustdoc.
3. crates/webui-handler/src/lib.rs - compile-time assert_send_sync::<WebUIHandler>() inside the existing #[cfg(test)] module to fail-fast if a future field breaks Send or Sync.

Why

I'm wiring a WebUIHandler into a Tokio/Axum-shaped request path in an embedded host. The first question is "can I store one of these in axum::extract::State and serve concurrent requests from it, or do I need a per-task instance or a mutex?". Today, that question is answered only indirectly:

• The existing doc says "stateless ... allowing concurrent renders with &self" - which strongly implies Send + Sync, but doesn't say so.
• WebUIHandler has a single private field (Option<fn() -> Box<dyn HandlerPlugin>>), so the auto-traits do hold - but an adopter can't see the field from the public API and has to either reason about it from the struct definition or try compiling and find out.

Stating Send + Sync explicitly in both the rustdoc and the integration page removes that lookup. The static assertion keeps the docs honest if someone later adds a RefCell / Rc field.

How I tested

cargo check -p microsoft-webui-handler --tests

(passes - the assert_send_sync block compiles, confirming WebUIHandler: Send + Sync today.)

Notes

• Branch is users/janechu/document-webui-handler-thread-safety per my host repo's agent-driven branch convention.
• Sibling of chore: correct rust integration docs to match published crate #295 and chore: correct node integration docs to match published render() signature #296. The three PRs in this trio (rust docs, node docs, this) are independent.

[mohamedmansour]

WebUIHandler is already thread-safe. Current code has handle(&self), creates a fresh per-render WebUIProcessContext, and creates plugin instances per render from a factory. Concurrent renders can run in parallel with no Mutex.

I see some issues, The added rustdoc says per-render state is created inside render, but the method is handle; there is no Self::render. You need to change [render](Self::render) to [handle](Self::handle).

Another issue DESIGN.md still contradicts the thread-safety contract. Update DESIGN.md to match current code: factory function field, with_plugin(factory: fn() -> Box<dyn HandlerPlugin>), and handle(&self, ...), plus the explicit Send+Sync/thread-safe contract.

PR should say “already thread-safe” and update the stale spec/incorrect rustdoc link before merging.

[janechu]

Thanks for the review! Fixed in fbe0e3de. Summary of changes:

Rustdoc link (crates/webui-handler/src/lib.rs)
You're right that handle is the canonical documented entry point — the integration page and the rest of the rustdoc all use it. Changed both [render](Self::render) references to [handle](Self::handle). (For the record, a public render() method does still exist on WebUIHandler — it's the writer-doesn't-call-.end() variant of handle() — but routing the docs through handle is clearly the right framing, so I went with your suggestion.) Also reworded to "is already Send + Sync" so the framing is unambiguous that this PR documents an existing property.

While I was in the doc-comment I also dropped a broken intra-doc link: the original additions linked to [WebUIProcessContext], which is a private type, so cargo doc emitted a private_intra_doc_links warning. Replaced with plain code text.

DESIGN.md (Handler Implementation section)
Updated to match current code:

• struct field: plugin: Option<Box<dyn HandlerPlugin>> → plugin_factory: Option<fn() -> Box<dyn HandlerPlugin>>
• with_plugin(plugin: Box<dyn HandlerPlugin>) → with_plugin(factory: fn() -> Box<dyn HandlerPlugin>)
• handle(&mut self, ...) → handle(&self, ...)
• New "Thread safety" subsection making the Send + Sync / Arc-without-Mutex contract explicit in the spec.

I also fixed the render_partial/render_action_response/render_component_templates signatures further down in the same section while I was in there — they were stale in the same way (showed handler: &mut WebUIHandler as the first parameter, which contradicts the thread-safety story; the actual functions in route_handler.rs don't take a handler at all). Happy to drop that part of the change if you'd prefer to keep this PR strictly scoped, but it felt tightly coupled to the same fix.

Verified locally:

• cargo fmt --all --check ✔
• cargo clippy --workspace -- -D warnings ✔
• cargo xtask license-headers ✔
• cargo doc -p microsoft-webui-handler --no-deps ✔ (zero warnings)
• cargo test -p microsoft-webui-handler --lib ✔ (285 passed, including the new assert_send_sync::<WebUIHandler>() compile-time check)

[mohamedmansour]

Why do we need an example for thread safety, the docs state thread safety, we don't need more doc bloat showcasing how we can run the handler N times