Add AOT smoke test to CI

[tig]

Summary

Adds an AOT runtime regression test to CI that actually publishes and runs the NativeAot example binary.

Changes

1. **\Examples/NativeAot/Program.cs**: Added --smoke-test\ flag that:

   • Creates all 25+ views (same AOT-sensitive codepaths as interactive mode)
   • Exercises ConfigurationManager, deep cloning, JSON serialization
   • Exits with success message instead of entering interactive event loop

2. **.github/workflows/build-validation.yml**: Added \AOT Smoke Test\ step that runs the published AOT binary with --smoke-test\ after the existing \dotnet publish\ step.

Why

The existing CI only does \dotnet publish\ which catches compile-time AOT issues (trimming warnings, IL linker errors). But some AOT bugs only manifest at runtime — e.g., reflection-dependent Dictionary constructors, missing type metadata, serialization failures. This smoke test catches those.

Testing

• Built and verified locally
• The smoke test creates all views, verifies no crashes, and prints success message

[BDisp]

The real exceptions in AOT only manifest themselves at runtime with the release configuration, using the NuGet package from the local_packages folder.

[tig]

The real exceptions in AOT only manifest themselves at runtime with the release configuration, using the NuGet package from the local_packages folder.

Can you make a specific recommendation on what should change here?

[BDisp]

Can you make a specific recommendation on what should change here?

I remember when I created the NativeAot project, there was a Debug configuration that used a reference to the Terminal.Gui project for immediate debugging purposes, and a Release configuration that used the latest NuGet package in the local_packages folder, which caught all compilation errors that weren't detectable through the Debug configuration. It seems this has been changed now, which doesn't give any certainty as to whether AOT is actually working correctly or not.

[BDisp]

Currently, I don't see anything related to trimmers in the NativeAOT project.

[tig]

@BDisp see the updated PR description. This test should now test end-to-end and catch almost all aot issues.

[BDisp]

@BDisp see the updated PR description. This test should now test end-to-end and catch almost all aot issues.

I see. It looks like it might work. Be aware that sometimes it compiled fine in the Release configuration, successfully publishing the executable, but when run it still threw exceptions that weren't caught at compile time. I don't know if CI will also address these cases.

[tig]

@BDisp see the updated PR description. This test should now test end-to-end and catch almost all aot issues.

I see. It looks like it might work. Be aware that sometimes it compiled fine in the Release configuration, successfully publishing the executable, but when run it still threw exceptions that weren't caught at compile time. I don't know if CI will also address these cases.

Part of why the test intentionally uses a bunch of View sub-classes and enables CM.

[BDisp]

Ideally, you should test with the most recently generated NuGet package because it may even contain some fixes that will be needed in the most recent release. At least try running the published file manually, because the published file is different from the file created in the Release configuration.
Well, I'm going to rest now.

[harder]

I ran this through my local Copilot agent where I was testing the previous AOT fixes. Here is some feedback.

1. A Windows NativeAOT publish-and-run smoke test would be valuable, if possible.

• The actual AOT: #5243 fix not effective at runtime — Dictionary<ColorName16, string> still crashes in 2.1.0-rc.1 #5248 failure was reported on win-x64, and my local verification showed that even the known-broken rc.1 state passes the same style of smoke test on osx-arm64.
• So this PR’s current ubuntu-only smoke test is valuable, but it is not sufficient for the bug class that just escaped.
• Most valuable addition: run the same published binary smoke test on windows-latest too, ideally with an OS matrix.

2. A downstream-package consumer smoke test, not just the in-repo project-reference example

• Examples/NativeAot/NativeAot.csproj still uses a ProjectReference to Terminal.Gui, not a PackageReference to the just-packed ./local_packages nupkg.
• The closest match to the real failure mode is pack Terminal.Gui, restore a tiny temp app from local_packages, publish AOT, run it.
• This is the exact harness shape I used in the session workspace, and it avoids assuming the in-solution example exercises the same downstream package-consumer path.
• Concrete recommendation: keep Examples/NativeAot if you want, but add a second CI smoke app that references the freshly packed Terminal.Gui package from ./local_packages and runs after dotnet pack.

3. Explicit dictionary-clone coverage in --smoke-test

• Right now the smoke test relies on “full app lifecycle + all views” to indirectly hit the sensitive config paths.
• That’s broad, but it doesn’t explicitly assert the exact dictionary surfaces that caused the recent failures.
• Useful addition: in --smoke-test, directly call DeepCloner.DeepClone (...) on the current config dictionaries that matter:
• Color.Colors16
• Application.DefaultKeyBindings
• View.DefaultKeyBindings
• View.ViewKeyBindings
• ThemeManager.Themes
• SchemeManager.Schemes
• This gives a more targeted failure if a future regression lands in CreateDictionaryInstance again.

[tig]

@copilot see #5251 (comment)

Do not do #2, but do the #1 and #3. We will create another PR for #2.

[Copilot]

@tig I've opened a new pull request, #5255, to work on those changes. Once the pull request is ready, I'll request review from you.

[tig]

FWIW: Check out https://github.com/gui-cs/clet#native-binaries-install

I do believe this is the first instance of a full TG app published as native AOT that really, truly, works!