[TrimmableTypeMap] NativeAOT end-to-end validation #11052

Part of #10788

Summary

The entire motivation for the trimmable type map is NativeAOT support, but there is no issue tracking end-to-end validation of building and running an app with NativeAOT + trimmable type map.

Why this matters

NativeAOT has unique concerns that differ from the CoreCLR + ILLink path:

1. ILC post-trim type list — ILC does not yet expose the list of types it kept in the type map (tracked in TypeMap API: For trimmed and nativeaot builds, provide a list of the types kept by the typemap runtime#120204). This is needed for post-trim ProGuard generation. The current workaround is $(IlcGenerateMetadataLog) / $(IlcGenerateDgmlFile), but these are large and slow to parse.
2. No ILLink custom steps under NativeAOT — the trimmable path avoids custom trimmer steps, but we need to verify ILC's TypeMap intrinsic handles our attributes correctly (trim targets, aliases, associations).
3. MakeGenericType restrictions — NativeAOT restricts MakeGenericType to pre-compiled generic instantiations. While [TrimmableTypeMap] Handle generic invoker type resolution at runtime #11046 showed this is not a real concern for invoker types, we should validate there are no other paths that hit this.
4. ProGuard generation after ILC — the build pipeline needs different plumbing to generate ProGuard rules from ILC output vs ILLink output ([TrimmableTypeMap] Generate ProGuard for types in type map #10790).
5. crossgen2 is N/A — the perf optimization of pre-compiling the NativeHashtable via crossgen2 ([TrimmableTypeMap] Performance considerations #10795) only applies to CoreCLR. NativeAOT pre-compiles the lookup intrinsically, but we need to verify the startup perf is acceptable.

Acceptance criteria

• A sample app (at minimum HelloWorld-level, ideally with AndroidX) builds successfully with PublishAot=true + _AndroidTypeMapImplementation=trimmable
• The app launches and runs on a device/emulator
• Type map lookups work: managed-to-Java and Java-to-managed
• JCW registration via RegisterNatives works
• ProGuard rules are generated correctly from ILC output
• No MakeGenericType or reflection failures at runtime
• Startup time is measured and compared to CoreCLR + trimmable baseline

Dependencies

• TypeMap API: For trimmed and nativeaot builds, provide a list of the types kept by the typemap runtime#120204 — ILC post-trim type list API (needed for ProGuard, can use workaround until available)
• [TrimmableTypeMap] Generate ProGuard for types in type map #10790 — ProGuard generation
• [TrimmableTypeMap] Implement pre-trimming build task #10789 / [TrimmableTypeMap] MSBuild task + targets wiring + incremental builds #10800 — Build pipeline must be functional first

Notes

This is a validation/integration issue, not a feature implementation issue. Most of the trimmable type map code is runtime-agnostic. The goal is to identify and fix any NativeAOT-specific gaps.