feat(playground): a guided tutorial that runs EF Core + SQLite in the browser

[pal-tamas]

Summary

Adds a guided tutorial to the playground, whose last four chapters run real EF Core against real SQLite inside the browser tab. A reader can now go from the front page to "I wrote an entity, saved a row and queried it back" with nothing installed — then hand off to docs/tutorial for the parts that need a machine (rask new, migrations, jobs, mail, deploy).

The left pane gains a Tutorial tab beside the example gallery: eight chapters, each with its goal and what to notice above the editor, prev/next navigation, and a tick once the chapter compiles (your edits included — the tick means it built, not you clicked).

#	Chapter	Teaches	DB
1	Your first component	Render(), tag factories, the children indexer	–
2	State and events	a field, a handler, automatic re-render	–
3	Composition and lists	a child component's generated factory, Key:	–
4	Forms and validation	Form<T>, two-way Input(() => model.Field), Validate:	–
5	Your first entity	Entity<Guid>, a DbContext, EnsureCreated(), an insert	✔
6	Query and display	LINQ over a DbSet, translated to SQL	✔
7	Edit and delete	an update, then soft delete and the query filter that hides it	✔
8	Relationships	a navigation property, saving a graph, Include()	✔

Chapters 5–8 teach the same Rask.Data conventions rask generate feature scaffolds — Entity<Guid>, ApplyRaskConventions(), the auditing/soft-delete interceptors — so what a reader learns in the browser is what they write on their machine.

The framework bug this uncovered

OnMountAsync never ran for any playground snippet, and never had. A component normally enters the tree through its generated factory, and that factory's GetOrCreate is what registers the instance with its parent. The playground builds each compiled component with ActivatorUtilities, so it arrived as a plain object: it rendered, but was invisible to the alive-set walk — no OnMount, no OnMountAsync, no OnRendered, no OnUnmount, and no handle to re-render through when an async hook completed.

The failure is silent and looks exactly like code that doesn't work. Here it surfaced as chapter 5's EnsureCreatedAsync never running, then the insert reporting no such table: Products — I chased it as a SQLite problem before an io-only probe (no EF Core at all) rendered nothing either.

New public Mount in Rask.Core fixes it: Div()[Mount(Child: instance)] adopts and notifies the instance exactly as the framework's own wrapper roots do for theirs, and adds no markup of its own. Wrapping a factory-built child is a harmless no-op. Rask.Testing already solved this internally for RaskTest.Render (#583); this is the same fix for app code.

Build

SQLite in WASM means linking e_sqlite3 (a static archive) into the runtime — a native relink, so the playground now publishes with wasm-tools. That is gated so the fast paths are untouched:

• RaskPlaygroundData follows the csproj's existing WasmBuildNative guard (as InvariantGlobalization and RunAOTCompilation already do). The fast no-native build ships without the EF Core reference set and marks chapters 5–8 read-only with Run disabled — rather than pretending they work and filling the preview with CS0246.
• scripts/run-unit-local.sh and the slnx build in the E2E gate are unchanged — still fast, still workload-free.
• pages.yml already installs wasm-tools and publishes without the flag, so the deployed site gets the full track with no workflow change.
• The playground publish in run-e2e-local.sh drops -p:WasmBuildNative=false, and also drops --no-restore: RaskPlaygroundData changes the package graph, and MSBuild silently ignores a PackageReference that appeared after restore — the bundle would have defined RASK_PLAYGROUND_DATA while shipping no EF Core at all.
• NoWarn=WASM0001 for SQLite's varargs natives (sqlite3_config), which warnings-as-errors would otherwise turn into a failed publish.

Testing

• TutorialChaptersTests — every chapter compiles through the real PlaygroundCompiler, and the data chapters actually reach SQLite: seed, save, query back, with the entity chapter asserting an insert through a real click. Also pins the ch{N}.db convention that Reset derives its file name from, and that pooling stays off.
• MountTests — pins both directions: an unadopted instance renders but never mounts (the bug), and Mount runs the sync and async lifecycle including the re-render on completion.
• TutorialPaneStateTests — keeps the E2E's DOM hooks and the markup in step, in the fast gate rather than as a browser timeout (the IdeBadgeState pattern from The browser E2E gate cannot pass on main: the playground test waits for a class #470 deleted #593).
• PlaygroundExampleTests — the acceptance test, and the only thing that can prove this at all: chapter 5 creates the database, inserts through the compiled component's own handler and renders the row; Next → chapter 6 seeds and queries Cold brew back. Passing against the native publish.
• dotnet format + warnings-as-errors build + full unit suite green.

Also verified in a real browser via a scripted Playwright pass: the editor survives tab switches (hosts=1, monacoAlive=true, brief never inside the host), the tab loads the code the pane highlights in both directions, and on a no-data build chapter 5 renders is-locked with Run genuinely disabled.

Review

A high-effort /code-review found 10 real defects, all fixed — most seriously the brief band shifting the Monaco host's child slot so the positional diff rewrote the live editor, the tab switch leaving the editor showing a different chapter than the brief claimed, and the --no-restore package-graph mismatch above. Worth noting one dead end the fix comments record: keying the two children looks like the obvious fix and is worse — a keyed host is re-created by the full-document morph, orphaning the editor Monaco mounted into, which I only caught by screenshotting.

Benchmarks: not applicable. The framework diff is one new file (Mount.cs, 49 lines); no existing render or live-runtime path is touched.

Docs

docs/playground.md (tutorial section + honest limitations), docs/composition.md (hosting a component you built yourself), docs/sqlite.md, docs/data-access.md, docs/tutorial/00-overview.md, README.md, llms.txt, CHANGELOG.

docs/sqlite.md's "SQLite in the browser?" section said it isn't viable. It is — this PR ships it — so that caveat is now scoped to what actually still bites (durability, plus the untrimmed and WASM0001 constraints). Durable client-side SQLite over OPFS is being designed separately in #642, so this deliberately leaves that rewrite to it rather than half-doing it here.