fix: resolve NU1903 for SQLitePCLRaw.lib.e_sqlite3 by pinning SQLitePCLRaw 3.x

[adrianhall]

Summary

Closes #492 (the remaining half of #489's NU1903 triage).

Microsoft.EntityFrameworkCore.Sqlite floats a transitive dependency on SQLitePCLRaw.bundle_e_sqlite3 2.1.11, which pulls in the deprecated SQLitePCLRaw.lib.e_sqlite3 2.1.11 and triggers:

warning NU1903: Package 'SQLitePCLRaw.lib.e_sqlite3' 2.1.11 has a known high severity vulnerability, https://github.com/advisories/GHSA-2m69-gcr7-jv3q

The issue (and the advisory itself) says no patched version of lib.e_sqlite3 exists — but that's now out of date. The SQLitePCLRaw 3.x line (released after the advisory) drops lib.e_sqlite3 entirely and depends on SourceGear.sqlite3 3.50.4.5 instead (SQLite 3.50.4, above the advisory's 3.50.2 fix line), with full native runtimes/ asset coverage for android-*, ios*, maccatalyst*, browser-wasm, linux-* (incl. musl), osx-*, and win-* RIDs. This is exactly Option 1 from the issue's own comment thread — no code changes required, just a version pin.

Is this ALSO a problem with the main packages?

Yes (per the open question in the issue thread): it affects both the main library/test build and every downstream consumer, for two different reasons:

1. Main packages/tests (src/CommunityToolkit.Datasync.Client, tests/CommunityToolkit.Datasync.TestCommon, tests/CommunityToolkit.Datasync.TestService) restore under central package management. Adding <PackageVersion Include="SQLitePCLRaw.bundle_e_sqlite3" Version="3.0.3" /> to the root Directory.Packages.props and letting CentralPackageTransitivePinningEnabled do its job resolves it everywhere in the main solution — mirrors the Microsoft.OpenApi NU1903 fix from Audit sample projects for stale/inconsistent NuGet package pins and NU1903 vulnerability warnings #489/fix: resolve remaining sample package drift and Microsoft.OpenApi NU1903 #493 exactly (no PackageReference needed anywhere for either package).
2. Samples: central-package pinning is solution-local and isn't baked into CommunityToolkit.Datasync.Client's published nuspec, so every sample that consumes it via PackageReference (rather than ProjectReference) still floats the vulnerable version on its own. Added the identical explicit SQLitePCLRaw.bundle_e_sqlite3 override to the 7 affected samples: TodoApp.Avalonia, TodoApp.MAUI, TodoApp.WPF, TodoApp.WinUI3, TodoApp.Uno (via its own local Directory.Packages.props), todoapp-tutorial/ClientApp, and todoapp-blazor-wasm/TodoApp.BlazorWasm.Client. TodoApp.Avalonia.Desktop needed no change — it inherits the pin transitively via its ProjectReference to TodoApp.Avalonia (verified via restore).

Changes

• Directory.Packages.props: pin SQLitePCLRaw.bundle_e_sqlite3 to 3.0.3, with an explanatory comment (same style as the existing Microsoft.OpenApi pin).
• 7 sample .csproj/Directory.Packages.props files: add the same explicit SQLitePCLRaw.bundle_e_sqlite3 override.

No source code changes.

Verification

• dotnet restore / dotnet build / dotnet test on Datasync.Toolkit.sln: clean restore (no NU1903), build succeeds with 0 warnings/0 errors, and all 12 test assemblies report Test Run Successful (2280 unique tests passing, 465 skipped as expected for live-service tests).
• Confirmed every restored project.assets.json under src//tests/ now resolves sqlitepclraw.bundle_e_sqlite3/3.0.3 (config/core/provider at 3.0.3 too), with zero occurrences of sqlitepclraw.lib.e_sqlite3 anywhere in the graph.
• Verified restore (and build, where the target platform doesn't need a missing workload) for TodoApp.Avalonia, TodoApp.Avalonia.Desktop, TodoApp.BlazorWasm.Client, todoapp-tutorial/ClientApp, TodoApp.WPF, and TodoApp.WinUI3 — all clean, no NU1903, SQLitePCLRaw resolves to 3.0.3. The Blazor WASM build even confirms a native browser-wasm asset (e_sqlite3.a) is present in SourceGear.sqlite3.
• TodoApp.MAUI (net10.0-android) and TodoApp.Uno's mobile TFMs could not be restored in this environment due to missing Android/iOS workloads — the same limitation already noted in fix: resolve remaining sample package drift and Microsoft.OpenApi NU1903 #493's PR description. The pin is applied identically to these projects and is expected to resolve the same way once those workloads are available, consistent with every other affected project in this PR.

Follow-up

None identified. The unrelated NU1903 warning for Tmds.DBus(.Protocol) surfaced while restoring TodoApp.Avalonia.Desktop/TodoApp.Uno is out of scope for this issue and not touched here.

[adrianhall]

Pushed a follow-up commit documenting this fix in docs/in-depth/client/index.md:

• Added a note under "Creating an offline-capable DbContext" pointing consumers at the SQLitePCLRaw.bundle_e_sqlite3 3.0.3 override if they hit this NU1903 warning in their own application.
• Fixed the "Blazor WASM and Blazor Hybrid" admonition immediately above that section — it used an unquoted, bold title (!!! note **Blazor WASM and Blazor Hybrid**), which the admonition markdown extension's title parser doesn't accept. The whole block was silently failing to render as an admonition (falling back to a plain paragraph with the literal !!! note **...** text). Quoting the title fixes it: !!! note "Blazor WASM and Blazor Hybrid". Verified against python-markdown + pymdownx.superfences (the extensions configured in mkdocs.shared.yml) that both admonitions now render correctly, including the nested fenced xml code sample in the new note.

Also filed #499 for a separate, unrelated NU1903 (Tmds.DBus/Tmds.DBus.Protocol, GHSA-xrw6-gwf8-vvr9) discovered while restoring the Avalonia/Uno desktop-head samples during verification of this fix.

[adrianhall]

Pushed one more fix: the second broken admonition I flagged earlier.

`!!! warning DO NOT USE THE SAME ENTITY TYPE FOR BOTH SERVICE AND CLIENT` used an unquoted, all-caps multi-word title. Unlike the first admonition (which failed to parse as a block at all), this one does render as an admonition, but the title parser swallows the unquoted words into the block's CSS class list instead of using them as the title — so it silently fell back to the generic "Warning" title (losing the intended custom title) and polluted the <div>'s class attribute with the lowercased title words.

Fixed by quoting the title: !!! warning "Do not use the same entity type for both service and client". Verified against python-markdown + pymdownx.superfences — now renders as <div class="admonition warning"> with the correct custom title in the title bar.

[adrianhall]

Pushed one more commit: added a "Building the documentation site" section to README.md documenting the mkdocs serve/mkdocs build workflow (venv, pip install mkdocs mkdocs-mermaid2-plugin, localhost:7000), and added .venv-*/ to .gitignore so a local docs venv doesn't get accidentally committed.