feat(ksp): migrate the Kotlin processor from kapt to KSP

[LMLiam]

Problem

The processor is consumed via kapt, which JetBrains has placed in maintenance mode in favor of KSP/KSP2. kapt generates Java stubs for every Kotlin compilation (slow) and is not the recommended path going forward. Offering a KSP implementation would speed up Kotlin consumer builds and future‑proof the tool.

Evidence

• README/CONTRIBUTING document kapt as the Kotlin integration (README.md:40,53, links to the kapt docs README.md:58).
• The build applies org.jetbrains.kotlin.kapt (build.gradle:4, subprojects { apply plugin: 'org.jetbrains.kotlin.kapt' }).
• The current processor is a javax.annotation.processing.Processor (ServiceSchemeProcessor.kt), which works under kapt/javac but cannot be used by KSP directly.

Proposed implementation

• Add a KSP SymbolProcessor/SymbolProcessorProvider implementation (new module, e.g. modules/processor-ksp) that reuses the same contract/provider discovery and META-INF/services generation logic, sharing core code where practical.
• Publish it as an additional artifact (e.g. spi-tooling-processor-ksp) and document ksp(...) wiring in the README alongside (or instead of) kapt.
• Keep the javax processor for Java/annotationProcessor consumers.

Acceptance criteria

• A Kotlin project can register the processor via ksp(...) and get identical META-INF/services output.
• Tests cover the KSP path (e.g. via kotlin-compile-testing's KSP support).
• README documents kapt vs KSP vs annotationProcessor.

---

✅ Triage decision (2026-06-06)

Migrate the Kotlin path off kapt entirely to KSP (kapt is in maintenance mode). KSP becomes the supported Kotlin integration; remove kapt from the build and docs.

• Implement a KSP SymbolProcessor/SymbolProcessorProvider mirroring the current discovery, validation, and META-INF/services generation.
• The javax annotationProcessor path stays for Java consumers (KSP does not process Java sources).
• Breaking change for Kotlin consumers: kapt(...) → ksp(...). README (docs(readme): fix incorrect Maven coordinates in the Quick Start #22, docs(readme): fix typos and broken links in README and CONTRIBUTING #33), CHANGELOG (docs(changelog): add a CHANGELOG and accurate release docs #34), and the Gradle convention plugin (feat(gradle-plugin): auto-wire SPI tooling via a convention plugin #40) must be updated to KSP. The kapt-specific incremental note in fix(processor): register for Gradle incremental annotation processing #14 applies only to the remaining javax/Java path.

[LMLiam]

Triage — strategic decision. A KSP variant adds a new published artifact and a second processor implementation to maintain alongside the kapt/javax one. Confirm: commit to KSP now (kapt is in maintenance mode)? Should KSP replace kapt in the docs or run alongside it? Relates to #40 (a convention plugin would select ksp() when present).

[LMLiam]

Triage — strategic decision. A KSP variant adds a new published artifact and a second processor implementation to maintain alongside the kapt/javax one. Confirm: commit to KSP now (kapt is in maintenance mode)? Should KSP replace kapt in the docs or run alongside it? Relates to #40 (a convention plugin would select ksp() when present).

We should move away from kapt completely and move to the newer solution (KSP)