TodoApp.Uno: WASM0001 sqlite3_config/db_config varargs warnings on browserwasm head #543

Summary

The browserwasm head 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:     System.Int32 sqlite3_config_int(System.Int32, System.Int32) (in [SQLitePCLRaw.provider.e_sqlite3] SQLitePCL.SQLite3Provider_e_sqlite3+NativeMethods)
... (several more sqlite3_config_*/sqlite3_db_config_* overloads) ...
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: https://github.com/CommunityToolkit/Datasync/actions/runs/29093946725 (todoapp-uno / browserwasm job)

This is pre-existing to the SQLitePCLRaw.bundle_e_sqlite3 package (pinned in Directory.Packages.props for the unrelated NU1903 fix in #492) combined with the WebAssembly SDK's native-interop checks - it's not caused by #524/#525/#526's changes, just newly visible now that browserwasm builds successfully for the first time (previously blocked first by #506's NU1605 restore failure, then by #525's UXAML0001, then by the Uno.Wasm.Bootstrap TFM guard fixed in #524).

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 WASM SDK's build-time analyzer flags all of them anyway as a blanket "any varargs-shaped native symbol is risky" warning, even though the app's actual EF Core + SQLite usage path (plain CRUD via AppDbContext) doesn't call sqlite3_config/sqlite3_db_config directly at all.

Suggested fix / investigation

1. Confirm (ideally via manual testing in a browser, since this can't be verified through dotnet build alone) that the sample's actual SQLite usage never exercises these specific varargs code paths at runtime - if so, this is diagnostic-only noise, matching the pattern of IL2026/IL2104 trim analysis warnings on TodoApp.Avalonia.iOS build #521/fix: suppress IL2026/IL2104 trim analysis warnings on mobile TodoApp samples #531 and the new IL2026/IL2104/IL2121 issue filed for this PR.
2. If confirmed harmless, evaluate whether it can/should be suppressed (this is emitted by Microsoft.NET.Runtime.WebAssembly.Sdk's WasmApp.Common.targets, not a standard MSBuild NoWarn-able diagnostic in the usual sense - may need -p:WasmAllowUndefinedSymbols or a similar WASM-specific suppression flag; needs investigation into what mechanism this SDK actually supports).
3. If not confirmed harmless (i.e. some code path in this sample or in CommunityToolkit.Datasync.Client/EF Core Sqlite does hit one of these varargs entry points on WASM), that would need an actual runtime fix (likely a SQLitePCLRaw provider/version change), not just a warning suppression.