Spring Boot startup time: bean-by-bean diagnosis, and one directory per post

Adds spring-boot-startup-time/, the companion project for BLOG-618: a runnable
Spring Boot 4.1.1 application on JDK 25 that installs BufferingApplicationStartup
and FlightRecorderApplicationStartup behind a system property, and a /diag/startup
endpoint that computes step self time -- the number /actuator/startup does not give
you and the one that names the actual culprits.

Captured under docs/output/: the step tree sorted both ways, the same startup as JFR
events, a +5000-class experiment putting 0.11 ms per scanned class on the classpath
scan tax, the silent truncation a 2048-step buffer performs, and JDK 25 AOT cache
timings (6.93 s to 4.82 s). Post body and metadata live in post/.

Moves the existing Actuator project into actuator-in-production/ so the repository
holds one directory per article; the root README is now an index.

spring-boot-startup-time/docs/output/01-api-corrections.txt

@@ -0,0 +1,56 @@
+=== Where getApplicationStartup() actually lives (Spring Framework 7.0.9) ===
+
+Injecting ApplicationContext and calling getApplicationStartup() does not compile:
+
+  [ERROR] .../config/StartupBeans.java:[22,45] cannot find symbol
+    symbol:   method getApplicationStartup()
+    location: variable context of type org.springframework.context.ApplicationContext
+
+javap says the accessor is declared one interface down, and also on the bean factory:
+
+  $ javap -cp . org.springframework.context.ConfigurableApplicationContext | grep ApplicationStartup
+    public abstract void setApplicationStartup(org.springframework.core.metrics.ApplicationStartup);
+    public abstract org.springframework.core.metrics.ApplicationStartup getApplicationStartup();
+
+  $ javap -cp . org.springframework.beans.factory.config.ConfigurableBeanFactory | grep ApplicationStartup
+    public abstract void setApplicationStartup(org.springframework.core.metrics.ApplicationStartup);
+    public abstract org.springframework.core.metrics.ApplicationStartup getApplicationStartup();
+
+=== The buffering API surface (spring-boot 4.1.1) ===
+
+  $ javap -cp . org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup
+  public class BufferingApplicationStartup implements org.springframework.core.metrics.ApplicationStartup {
+    public BufferingApplicationStartup(int);
+    public void startRecording();
+    public void addFilter(java.util.function.Predicate<org.springframework.core.metrics.StartupStep>);
+    public org.springframework.core.metrics.StartupStep start(java.lang.String);
+    public StartupTimeline getBufferedTimeline();
+    public StartupTimeline drainBufferedTimeline();
+  }
+
+  $ javap -cp . org.springframework.boot.context.metrics.buffering.StartupTimeline$TimelineEvent
+  public class StartupTimeline$TimelineEvent {
+    public java.time.Instant getStartTime();
+    public java.time.Instant getEndTime();
+    public java.time.Duration getDuration();
+    public org.springframework.core.metrics.StartupStep getStartupStep();
+  }
+
+Note: there is no setter for the buffer size and no Spring property that installs this.
+The only constructor takes the capacity, and it must be handed to SpringApplication
+before run().
+
+=== You do not need a @Bean method for it ===
+
+Declaring one produces a startup failure, because Boot has already registered the
+instance as a singleton:
+
+  Parameter 0 of constructor in com.ankurm.startup.web.StartupDiagnosticsEndpoint
+  required a single bean, but 2 were found:
+        - bufferingApplicationStartup: defined by method 'bufferingApplicationStartup'
+          in class path resource [com/ankurm/startup/config/StartupBeans.class]
+        - applicationStartup: a programmatically registered singleton
+
+So the correct move is to inject ApplicationStartup directly and narrow with instanceof.
+Injecting BufferingApplicationStartup by its concrete type compiles and works -- until
+somebody runs without tracking, at which point the application will not start at all.