fix: render reachable-component ordering deterministically

[Jane Chu (janechu)]

Problem

Route-reachable components were collected into a HashSet<String> before emitting:

• CSS <link> hrefs (Link CSS strategy)
• CSS module specifiers (Module CSS strategy)
• Component template payloads / non-split template emission

Rust's HashSet iteration order depends on a per-process randomized hash seed (RandomState), so this emission order could change between renders / process restarts, even though the underlying data was already deterministic: collect_reachable_component_order_for_request already returns a deduplicated, traversal-ordered Vec<String> (see its sibling filter_needed_components doc comment: "Input order is preserved... so downstream <head> CSS <link> emission follows document/traversal order").

If two components apply competing same-specificity CSS (order, position, float, etc.) to elements inside a <for> loop, cascade resolution flips depending on which stylesheet loaded last — this is the most plausible mechanism for <for>-repeated content visually landing in different positions across renders, since the <for> reconciliation itself (server process_*_for_loop and client element/diff.ts) is already fully array-order deterministic.

Fix

• Keep reachable as the traversal-ordered Vec<String> already produced upstream instead of collecting it into a HashSet<String>.
• Updated HandlerPlugin::emit_templates, HandlerPlugin::collect_template_payloads, and BootstrapExtensionContext::components to take &[String] instead of &HashSet<String> to match (the streaming checkpoint path already used borrowed slices). This is a minor breaking change to the public HandlerPlugin trait for any external plugin implementors; behavior for the two built-in plugins (webui, FAST) is unchanged aside from now-deterministic ordering.
• Updated the WebUI plugin implementation and its unit tests accordingly.
• Added link_strategy_emits_stylesheets_in_deterministic_document_order, a regression test asserting stylesheet <link> tags follow declared component order.

Code review checklist (framework change)

Applied the code-review skill checklist since this touches webui-handler core rendering:

• Determinism (§2): matches the documented anti-pattern/fix directly — "Iterating HashMap/HashSet for order-dependent logic" → "use insertion order / explicit ordering field." Replaced the HashSet<String> with the already-ordered Vec<String>.
• Allocation discipline (§4): net allocation decrease — removes the .collect::<HashSet<_>>() hash-table build entirely; the &[String] signature changes are zero-cost slice reborrows, no new clones.
• Data structure selection (§5): order-dependent iteration should use Vec/insertion order, not HashSet — this fix aligns the code with that rule.
• Cross-layer parity (§1): no client contract change — the client already looks up templates by tag name in a map (window.__webui.templates[tagName]), not by array position, so reordering the emitted payloads doesn't affect hydration correctness.

Testing

• cargo test -p microsoft-webui-handler — 454 unit tests + 35 streaming tests pass, including the new regression test.
• cargo xtask check — full gate (license-headers, fmt, clippy, deny, test, build, wasm build, examples, docs) passes.

Closes #520

Status: draft — pending resolution of reviewer feedback questioning whether this ordering should be a guaranteed contract; see discussion on #520.