Explain the dual behavior of @DisabledInAotMode (build-time vs runtime) and how Spring detects AOT mode.

## The two moments ### 1. Build-time: test AOT processing When you build a native (or AOT-optimized) **test** image, a `process-test-aot` phase runs. Spring's test AOT infrastructure (`TestContextAotGenerator`) discovers every **unique** test `ApplicationContext` configuration, **refreshes each one at build time**, and generates Java source that recreates it without runtime reflection/scanning. If a test's context mutates itself (mocks, dynamic bean registration), refreshing it during AOT generation typically **fails**. `@DisabledInAotMode` makes the generator **skip** that class, so it never tries to produce AOT artifacts for that context. ### 2. Runtime: execution in AOT mode When the application starts against generated artifacts, Spring is in **AOT mode**. This is signaled by the JVM system property **`spring.aot.enabled=true`** and queried in code via `org.springframework.aot.AotDetector.useGeneratedArtifacts()`. A **Spring-provided JUnit Jupiter `ExecutionCondition`** checks the annotation together with that flag and **disables** the test (JUnit reports it skipped) so it never runs against the frozen context. ## How AOT mode is detected — details - `AotDetector.useGeneratedArtifacts()` returns `true` when `spring.aot.enabled` is set to `true`. - You do not usually set this by hand for tests; the native/AOT test tooling sets it. But you *can* set `-Dspring.aot.enabled=true` to simulate AOT mode on the JVM against previously generated artifacts. - The same detector is what Spring's own framework code uses to decide whether to consume generated bean-registration code versus doing runtime processing. ## Why both effects are needed - Build-time skip alone would still let the test try to run in AOT mode (and misbehave). - Runtime disable alone would still let the build-time generator choke on the context. Together they make the test a clean no-op across the whole AOT pipeline while remaining a first-class test on the JVM. ## Gotchas / edge cases - Because it's conditional on AOT mode, code coverage and CI gates that only run plain JVM tests won't notice anything — the difference only shows in the native/AOT job. - Don't confuse it with JUnit's unconditional `@Disabled` or with `@DisabledIfSystemProperty` — `@DisabledInAotMode` is specifically wired to Spring's AOT detection and to the AOT generator. - It applies per unique context: two test classes sharing one context config are evaluated independently for annotation presence.