feat(examples): unified todo apps with SSR, MobX, and E2E suite

[janechu]

Pull Request

📖 Description

Adds a complete, unified Todo example surface to the examples/ tree
that showcases the same UI and behavior across three different rendering
strategies, and backs it with a shared end-to-end test suite.

What this PR delivers:

• examples/ssr/webui-todo-app — new SSR example built on declarative
  FAST HTML templates with @microsoft/webui prerendering and
  @microsoft/fast-html client-side hydration via
  RenderableFASTElement + defineAsync (defer-and-hydrate).
• Unified UI across all three todo apps —
  examples/csr/todo-app, examples/csr/todo-mobx-app, and the new SSR
  app render the same heading, form, filter <select>, list, and
  footer. The MobX app collapsed from five components to one to match
  the canonical layout while keeping the MobX bridge (singleton store,
  makeAutoObservable, single autorun) intact.
• Footer counter row (X items left · Y completed) in every todo
  app, finally surfacing the previously-unused computed counters on
  each store / state.
• New @microsoft/fast-examples-e2e workspace (examples/test/)
  with a shared Playwright suite that runs identically against every
  app via per-project DOM adapters. Specs use the .pw.spec.ts suffix
  so we can add Node .spec.ts tests later without collision.
• CI — npm run test:e2e is wired into ci-validate-pr.yml as a
  separate step after the existing unit-test job.
• @microsoft/webui bumped to 0.0.6 across the workspace.

This supersedes the approach from #7362 and replaces the older
imperative webui-todo-app example.

🎫 Issues

• Supersedes chore: add webui-todo-app example with declarative FAST HTML and webui prerendering #7362

👩‍💻 Reviewer Notes

A few intentional choices worth a closer look:

• @volatile on DefaultTodoList.activeCount / completedCount —
  required because the initial _todos array is empty, so without
  @volatile FAST captures the dependency graph only on first
  evaluation and never subscribes to item.done for items added later.
  Inline comments document this.
• Imperative syncCounts() in the SSR app — same pattern as the
  existing syncDescription() workaround for the fast-html text-binding
  hydration mismatch. SSR initial render does not include the counter
  text; it is populated client-side after hydration.
• Adapter design in examples/test/ — both CSR apps share
  createCsrAdapter() since their unified UI exposes the same
  selectors; the SSR app has its own adapter because items are rendered
  through a nested <todo-item> shadow root. See
  examples/test/DESIGN.md for the
  contributor guide.

📑 Test Plan

• npm run build — succeeds for all packages and example workspaces.
• npm run biome:check — passes.
• CI=1 npm run test:e2e — 21/21 passing across all three projects
  (6 baseline scenarios + 1 new footer-counters scenario × 3 apps).
• npm run test — fast-element and fast-html unit tests pass.
  Pre-existing Firefox flakiness in fast-test-harness (page.goto
  timeouts) is unrelated to this work; Chromium passes 46/46.
• npm run checkchange — no change file needed (no packages/*
  source edits).

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

⏭ Next Steps

• Investigate the underlying FAST observation behavior that requires
  @volatile on getters iterating reactive arrays — worth confirming
  whether this is by design or a bug that should be fixed in
  fast-element.

[chrisdholt]

Chromium test issues? Flaky or broken?

[janechu]

Chromium test issues? Flaky or broken?

No, just missing a changefile 🙃