Verify NativeAOT publication and JIT/AOT performance gates

Parent

Part of #19

What to build

Prove that the standalone analysis engine can be published as a NativeAOT-compatible library/runtime across the supported platform matrix and compare its editor-workload performance with the retained FCS baseline. The result is a measured release gate, not a claim based only on successful compilation.

Acceptance criteria

• The engine dependency closure passes trimming and NativeAOT analysis without runtime code generation, unconstrained reflection, dynamic loading, or reflection-based serialization.
• The supported platform matrix publishes and runs a smoke test for the standalone engine using the documented managed/native boundary.
• JIT and NativeAOT benchmarks cover cold project analysis, warm document edits, dependent refresh, concurrent requests, allocations, and the equivalent FCS baseline where applicable.
• The report defines explicit latency and allocation gates for the initial editor workload and records any platform-specific variance.
• A failed gate leaves the engine marked experimental and identifies the next constraint to remove; no replacement claim is made without differential correctness evidence.

Blocked by

• #24 — Prototype a NativeAOT-compatible incremental syntax and dependency core
• #26 — Implement the first engine-backed Project Mode feature slice

Start by reviewing blockers #24 and #26, then inspect the standalone engine's documented managed/native boundary and supported platform matrix. Run the NativeAOT smoke tests and JIT/NativeAOT editor-workload benchmarks, and finish when trimming analysis, platform execution, explicit latency and allocation gates, variance reporting, and the experimental fallback criteria are documented.