Native AOT or ReadyToRun for a .NET 8 Lambda with reflection-heavy dependencies?

The constraint

I'm deploying a .NET 8 ASP.NET Core Minimal API as an AWS Lambda behind scale-to-zero traffic, so cold-start latency is a hard SLO (under ~300ms). Microsoft documents both Native AOT (PublishAot=true) and standard self-contained publishing with ReadyToRun (PublishReadyToRun=true) as supported, but doesn't declare a default for this scenario.

The trade-off

Native AOT promises cold starts in the tens of milliseconds and a smaller memory footprint, but forbids dynamic code generation and requires reflection-used types to be annotated or preserved. My service currently depends on a few third-party packages whose AOT compatibility is unclear, and JSON serialization would need to move to System.Text.Json source generation. ReadyToRun keeps the full reflection ecosystem working but typically adds several hundred milliseconds of cold start and a much larger binary.

The uncertainty

I can audit trimming warnings (IL2026, IL3050) at build time, but I understand missing annotations can still surface as runtime exceptions only in the AOT binary, which makes me hesitant to commit without knowing the real risk surface.

Given a hard cold-start SLO and an unverified dependency graph, which path should I choose? Is the hybrid approach (thin AOT entry point delegating to a standard self-contained library) a practical middle ground, or does it just add deployment complexity? And how do teams validate that trimming warnings actually cover all runtime reflection paths before shipping AOT to production?