fix: suppress IL2026/IL2104 trim analysis warnings on mobile TodoApp samples

[adrianhall]

Summary

Fixes #521.

net10.0-ios (and mobile TFMs generally) enable the IL trim analyzer during dotnet build — not just dotnet publish — because these SDKs mark projects trimmable by default. This surfaced IL2026/IL2104 warnings on the TodoApp.Avalonia.iOS build (surfaced by the mobile CI added in #511 / PR #519), pointing at documented, trim-unsafe framework APIs:

• Avalonia's BindingPlugins.DataValidators (inherently reflection-based, by design)
• EF Core's DbContext(DbContextOptions) constructor (explicitly documented as not fully trim-compatible: https://aka.ms/efcore-docs-trimming)

Neither is a bug in the sample code — both are idiomatic, documented usage of their respective frameworks, exactly as taught in docs/samples/todoapp/avalonia.md.

Why suppress rather than fix the code

This repo's CI only ever runs dotnet build for these samples (see build-samples-todoapp-avalonia.yml / build-samples-todoapp-maui.yml) — never dotnet publish -p:PublishTrimmed=true. So today, trim analysis on these projects is purely diagnostic noise: no actual IL trimming/linking ever happens, and no app is shipped from this pipeline. Avoiding the flagged APIs would mean fighting Avalonia/EF Core's own recommended patterns for the sake of a warning with no functional consequence in a build-only pipeline, and would make the samples worse as teaching examples.

Changes

Added <SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings>:

• samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.iOS/TodoApp.Avalonia.iOS.csproj — the confirmed, reported case.
• samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.Android/TodoApp.Avalonia.Android.csproj — same shared code path (App.axaml.cs / AppDbContext.cs) is compiled under this TFM too; added precautionarily even though Android didn't surface the warning in the CI run that filed the issue.
• samples/todoapp/TodoApp.MAUI/TodoApp.MAUI.csproj — scoped to the net10.0-ios TFM only (via the GetTargetPlatformIdentifier conditional pattern already used elsewhere in this file), since the Android/Windows heads weren't confirmed to have the warning.

Each edit includes a comment explaining the root cause and linking back to #521.

Bonus: this also avoids the analyzer's build-time cost, not just its warning output

Per the actual Microsoft.NET.ILLink.targets shipped in the SDK:

<PropertyGroup Condition="'$(SuppressTrimAnalysisWarnings)' == 'true'">
  <_ExtraTrimmerArgs>$(_ExtraTrimmerArgs) --notrimwarn</_ExtraTrimmerArgs>
  <EnableTrimAnalyzer Condition="'$(EnableTrimAnalyzer)' == ''">false</EnableTrimAnalyzer>
</PropertyGroup>

Setting SuppressTrimAnalysisWarnings=true also sets EnableTrimAnalyzer=false (since we don't set EnableTrimAnalyzer explicitly ourselves), which disables the analyzer pass itself rather than merely hiding its output. Separately, the actual ILLink linking task (the potentially slow part) is only ever wired into the publish pipeline, not build — so it was never running here in the first place.

Testing

• dotnet build on the shared TodoApp.Avalonia.csproj and TodoApp.Avalonia.Desktop.csproj — succeeded (1 pre-existing, unrelated nullable warning).
• dotnet restore / dotnet build --configuration Release on Datasync.Toolkit.sln — succeeded, 0 warnings/0 errors. (This solution doesn't include the edited sample projects, confirming no impact on the core library.)
• dotnet test Datasync.Toolkit.sln --configuration Release — CommunityToolkit.Datasync.Client.Test: 1432/1432 passed. CommunityToolkit.Datasync.Server.Test had pre-existing, environment-only failures (no local Docker daemon; that suite depends on TestContainers) — confirmed identical failure count with the changes stashed out, so unrelated to this PR.
• Could not locally build the actual net10.0-ios / MAUI-iOS heads to visually confirm the warnings disappear (no Xcode/iOS workload available locally) — deferred to this repo's CI, which pins the exact Xcode/workload versions that originally surfaced the warnings.

Related

• Add CI workflow to build mobile /samples heads: Android, iOS, Uno (Phase 3 of #509) #511 / ci: add build-samples workflow for Phase 3 mobile heads (#511) #519 — Phase 3 samples CI rollout, where this was surfaced.