build: revisit the CycloneDX 2.4.1 pin once the Gradle 9.4.1 variant conflict is fixed

Tracking issue so a deliberate workaround does not quietly become permanent.

## Current state

`org.cyclonedx.bom` is pinned to **2.4.1** even though Spring Initializr ships **3.x** for
Spring Boot 4. The pin exists because cyclonedx 3.x fails at *configuration* time on Gradle
9.4.1 — a variant-mutation conflict on `:cyclonedxDirectBom`.

The cost of the pin is not just the old version. Spring Boot's `CycloneDxPluginAction` only
auto-configures the plugin version it recognises (3.x), so with 2.4.1 unrecognised it leaves
`cyclonedxBom` at plugin defaults — writing `build/reports/bom.json` and scanning the wrong
configuration set. `build.gradle.kts` therefore reproduces that configuration by hand:

```kotlin
tasks.named("cyclonedxBom") {
setOutputName("application.cdx")
includeConfigs.set(listOf("productionRuntimeClasspath"))
}
```

That output name and configuration set are load-bearing: `generateBinaryLicense`'s
completeness gate reads the SBOM at `build/reports/application.cdx.json` and compares it
against the shipped fat-jar classpath. If the SBOM silently moved or described a different
classpath, the LICENSE appendix would be wrong — and the gate exists precisely to stop that.

## Why this needs a tracker rather than a comment

The rationale is documented in `build.gradle.kts` and `AGENTS.md`, so it is discoverable. What
is not discoverable is *when it stops being necessary*. Once cyclonedx 3.x configures cleanly on
the project's Gradle version, the right move is to drop both the pin and the manual
configuration and let Spring Boot auto-configure the task — but nothing will prompt anyone to
check.

## What to do when picking this up

1. Try removing the version pin and the `tasks.named` block.
2. Confirm `./gradlew build` produces `build/reports/application.cdx.json` (not `bom.json`).
3. Confirm the SBOM lists the Spring Boot 4 modular jars and no stale Jackson 2 entries.
4. Confirm `generateBinaryLicense` still passes — it is the gate that catches a mis-scoped SBOM.
5. Confirm the actuator still serves `/actuator/sbom/application` in the `http` profile.

Context: the pin arrived with #23 (Spring Boot 4 + Spring AI 2.0 upgrade).

Read the rationale in build.gradle.kts and AGENTS.md, then try the listed Gradle build checks after removing the CycloneDX pin and manual task configuration. Done means application.cdx.json is produced, the SBOM has the expected Spring Boot 4 modular jars without stale Jackson 2 entries, generateBinaryLicense passes, and the HTTP profile still serves /actuator/sbom/application.

Written by the indexing model from the issue text.