Pass the project path to the kover aggregation dependency

[alexander-yevsyukov]

What

In KoverConfig.addAggregationDependency, build the root kover aggregation dependency from the subproject's path via the DependencyHandler.project(String) Kotlin DSL extension, instead of passing the Project instance itself as the dependency notation. Adds the org.gradle.kotlin.dsl.project import.

Why

Using a Project object as a dependency notation is deprecated since Gradle 9 and becomes a hard error in Gradle 10. The warning fires at configuration time of consumer builds (config's own build never calls KoverConfig.applyTo); it surfaced in delivery-server, where this exact fix is already applied and build-verified on the revive-admin-server-module branch. Landing it here keeps the next ./config/pull from overwriting that downstream copy with the deprecated form.

Notes for reviewers

• This was the only Project-as-notation call site in buildSrc; the other dependencies.add(...) sites (SpineCompilerCoverage.kt, TestKitCoverage.kt, ExcludeInternalDoclet.kt) pass string or Dependency notations and are unaffected.
• Behavior-preserving: same ProjectDependency on the same kover configuration, so the class KDoc ("adds a kover(project(...)) dependency") stays accurate.
• Consumers may still see one "Project as dependency notation" deprecation from inside Kover 0.9.8 itself (PrepareKover.kt, kotlinx-kover#818) — that instance is upstream's, not ours, and is tracked in team memory on the address-gradle-deprecations branch.
• Verified with ./gradlew :buildSrc:test detekt (the repo's documented command for buildSrc changes); spine-code-review and kotlin-engineer reviewers both approved with no findings.

🤖 Generated with Claude Code