Add CI workflow to build all /samples projects on PR #509

Summary

Surfaced during the #499 / #508 investigation (and noted as a gap in #507): /samples has no CI coverage at all today. None of the existing workflows (build-library.yml, build-docs.yml, build-template.yml) touch the samples/** path, so a PR can introduce a broken sample (bad package bump, breaking API change, stale TargetFramework, etc.) and nothing will catch it until someone manually opens the solution or a security scan flags a transitive dependency. That's effectively what happened with #492/#498/#499/#506 — none of those regressions were caught by CI.

This issue asks for a new workflow that builds every sample solution whenever a PR touches samples/**, mirroring the path-filtered pull_request trigger pattern already used by build-library.yml and build-template.yml.

Inventory of what needs building

Suggested approach

Given how heterogeneous the runner/workload requirements are across this list, a single dotnet build **/*.sln step won't work. Suggest a phased rollout instead of trying to cover everything in one PR:

1. Phase 1 — low-hanging fruit: add a build-samples.yml workflow (triggered on pull_request/push to main with paths: ['samples/**', '.github/workflows/build-samples.yml']) that builds the plain net10.0 samples with no extra workloads on ubuntu-latest: datasync-server, datasync-server-cosmosdb-singlecontainer, todoapp-tutorial, todoapp-mvc, todoapp-blazor-wasm, and the Avalonia shared+Desktop projects (TodoApp.Avalonia.csproj + TodoApp.Avalonia.Desktop.csproj) specifically (not the full .sln, to avoid pulling in the Android/iOS heads before workloads are set up).
2. Phase 2 — Windows-only heads: add a windows-latest job for TodoApp.WPF, TodoApp.WinUI3, and the MAUI Windows TFM.
3. Phase 3 — mobile heads: add android/ios/maui workload installation steps and build the Android/iOS heads for Avalonia, Uno, and MAUI. iOS builds will need a macOS runner. This phase should start with Avalonia (the pattern is simplest — 2 mobile heads, no Uno.Sdk complications) before attempting Uno, since Uno's desktop head is currently blocked by the unrelated NU1605 from Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506.
4. Consider continue-on-error: true (or excluding entirely) for any sample/head known to have a pre-existing, unrelated build break (e.g., Uno desktop per Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506) until that's fixed, so the new workflow doesn't start life red for reasons outside a given PR's control.

Should be build-only (dotnet restore + dotnet build), not run/test — most of these are UI apps without a practical headless test story today. A follow-up could explore headless Avalonia UI tests, but that's out of scope here.

Related

• Investigate resolving NU1903 for Tmds.DBus.Protocol in Avalonia desktop sample #499 / fix: resolve NU1903 for Tmds.DBus.Protocol in Avalonia sample by bumping to 11.3.18 #508 — Avalonia Tmds.DBus.Protocol NU1903 fix, merged with no CI verification beyond manual dotnet build.
• Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506 — Uno Tmds.DBus NU1903 investigation; blocked by the pre-existing Uno.WinUI NU1605 that this new workflow would also need to contend with.
• Major-version bump: Avalonia 11 → 12 (TodoApp.Avalonia sample) #507 — Avalonia 11 → 12 major-version-bump follow-up; explicitly called out the lack of samples CI coverage as a risk for that migration.