fix: suppress WASM0001 sqlite3_config/db_config varargs warnings on TodoApp.Uno browserwasm

[adrianhall]

Summary

Fixes #543.

The browserwasm head of TodoApp.Uno emits a block of WASM0001 warnings about unsupported native varargs functions in the bundled SQLite provider:

warning WASM0001: Found a native function (sqlite3_config) with varargs in e_sqlite3. Calling such functions is not supported, and will fail at runtime. Managed DllImports:
warning WASM0001:     System.Int32 sqlite3_config_none(System.Int32) (in [SQLitePCLRaw.provider.e_sqlite3] SQLitePCL.SQLite3Provider_e_sqlite3+NativeMethods)
...
warning WASM0001: Found a native function (sqlite3_db_config) with varargs in e_sqlite3. Calling such functions is not supported, and will fail at runtime. Managed DllImports:

CI run that surfaced this: https://github.com/CommunityToolkit/Datasync/actions/runs/29093946725 (todoapp-uno / browserwasm job)

Root cause

e_sqlite3's native sqlite3_config/sqlite3_db_config C functions are variadic (varargs), which the WebAssembly toolchain's managed-to-native interop cannot support. SQLitePCLRaw.provider.e_sqlite3 ships several fixed-arity P/Invoke overloads (sqlite3_config_none, sqlite3_config_int, sqlite3_config_log, etc.) to work around this for the specific configuration calls SQLitePCLRaw itself needs — the WebAssembly SDK's build-time native-interop check flags all of them anyway as a blanket "any varargs-shaped native symbol is risky" warning, even though this sample's actual SQLite usage (AppDbContext configured with UseSqlite against an in-memory connection in App.xaml.cs) never calls sqlite3_config/sqlite3_db_config directly.

Why suppress rather than fix the code

WASM0001 is emitted via TaskLoggingHelper.LogWarning(..., warningCode: "WASM0001", ...) in dotnet/runtime's WasmAppBuilder (PInvokeTableGenerator.cs → LogAdapter.Warning) — the standard MSBuild task-warning overload, which honors $(NoWarn)/warnings-as-errors filtering like any other build warning (CS*, NETSDK*, etc.). This repo already documents and uses exactly this suppression for the same warning on the Blazor WASM sample, in docs/in-depth/client/advanced/blazor-wasm.md (added in #394):

<PropertyGroup>
    <NoWarn>$(NoWarn);WASM0001</NoWarn>
</PropertyGroup>

Unlike the Blazor WASM sample — which never actually uses SQLite and instead removes the unused native asset before the workload check runs (see #523) — TodoApp.Uno genuinely configures EF Core with the SQLite provider on every head, including browserwasm, so that trick doesn't apply here. Suppression is the correct fix, matching the issue's own root-cause analysis.

Changes

• samples/todoapp/TodoApp.Uno/TodoApp.Uno/TodoApp.Uno.csproj — added <NoWarn Condition="...GetTargetPlatformIdentifier(...) == 'browserwasm'">$(NoWarn);WASM0001</NoWarn>, scoped to the browserwasm TFM only (the only head that runs the WebAssembly SDK's native-interop check), following the same GetTargetPlatformIdentifier-conditional pattern already used in this file for SuppressTrimAnalysisWarnings (see IL2026/IL2104 trim analysis warnings on TodoApp.Avalonia.iOS build #521/TodoApp.Uno: trim analysis warnings (IL2026/IL2104/IL2121) on browserwasm/ios/maccatalyst heads #534).
• docs/samples/todoapp/unoplatform.md — added a short callout about the WASM0001 warning on the browserwasm head, pointing readers at the more detailed blazor-wasm.md explanation for why it occurs and how to suppress it in their own projects.

Testing

• dotnet restore / dotnet build --configuration Debug on Datasync.Toolkit.sln — succeeded, 0 warnings / 0 errors. (This solution doesn't include the edited sample project, confirming no impact on the core library.)
• dotnet test Datasync.Toolkit.sln --no-build --configuration Debug — CommunityToolkit.Datasync.Client.Test: 1432/1432 passed, plus all non-container-dependent server test suites passed 100%. Server.Test/Server.MongoDB.Test/Server.EntityFrameworkCore.Test had pre-existing, environment-only failures (no local Docker daemon; those suites depend on TestContainers) — unrelated to this change, matching the precedent noted in fix: suppress IL2026/IL2104 trim analysis warnings on mobile TodoApp samples #531.
• Triggered build-samples.yml on this branch via workflow_dispatch: run 29150192782 — all jobs succeeded, including todoapp-uno / browserwasm, which now reports 0 Warning(s) (previously the block of WASM0001 warnings shown above), and the all-samples-built aggregation gate.

Related

• IL2026/IL2104 trim analysis warnings on TodoApp.Avalonia.iOS build #521 / fix: suppress IL2026/IL2104 trim analysis warnings on mobile TodoApp samples #531 / TodoApp.Uno: trim analysis warnings (IL2026/IL2104/IL2121) on browserwasm/ios/maccatalyst heads #534 — same class of fix (suppressing diagnostic-only build warnings that are harmless in this CI pipeline's build-only, never-published sample builds), applied earlier to trim-analysis warnings on the Avalonia/MAUI/Uno samples.
• (#330) Blazor WASM sample and docs updates. #394 — introduced the WASM0001 suppression pattern this PR reuses, for the Blazor WASM sample.
• Investigate resolving NU1903 for SQLitePCLRaw.lib.e_sqlite3 (no patched version exists) #492 / todoapp-blazor-wasm: benign NativeFileReference/WasmBuildNative warning from SQLitePCLRaw.bundle_e_sqlite3 override #523 — prior SQLitePCLRaw/native-asset handling this warning builds on.