Address Gradle 9.6 deprecations in build logic

[alexander-yevsyukov]

What & why

Gradle 9.6 (this repo is on 9.6.1) deprecates the Kotlin DSL delegated-property
accessors and several runtime APIs, all scheduled to become hard errors in
Gradle 10. This branch removes every such usage from our own build logic so
consumer repos that pull config don't inherit the nags.

Deprecations fixed in buildSrc (own code)

File	Before	After
jvm-module.gradle.kts, write-manifest.gradle.kts	val x by tasks.registering	tasks.register(...)
kmp-module.gradle.kts	val x by getting (source sets)	getByName(...)
jacoco-kotlin-jvm.gradle.kts, jacoco-kmm-jvm.gradle.kts, uber-jar-module.gradle.kts	val x by tasks.getting	tasks.named(...)
ProjectMetadata.kt	custom NonEmptyValue : PropertyDelegate	plain helper fun with explicit extra-fallback key

The migrations are behavior-preserving: getByName is exactly as eager as the
old by getting; register/named keep the tasks lazy; ProjectMetadata's
fallback keys (groupId/artifactId/version) and its failure modes on a
missing/non-String extra property are unchanged.

Verification

• ./gradlew -p buildSrc build (compile + tests) — green
• ./gradlew detekt (static analysis over buildSrc) — green
• --warning-mode all now shows zero deprecation warnings from our code

Residual third-party nags (documented, not fixable here)

Three warnings remain under --warning-mode all; all originate in plugins, not
our scripts, and no released versions fix them yet:

• Detekt 1.23.8 — ReportingExtension.file(String); fix ships only in
  Detekt 2.0 (still alpha), see detekt#8452
• Kover 0.9.8 — "Project object as dependency notation", see kotlinx-kover#818
• Gradle Doctor 0.12.1 — Project.getProperties; no newer release

These are captured in a new team-memory note
(.agents/memory/project/gradle-10-third-party-deprecations.md) so they get
re-checked on each dependency-update run rather than chased in buildSrc.
They must be resolved (or the plugins dropped) before adopting Gradle 10.

Note on branch scope

The branch also carries two earlier commits that predate this work and are
included in the diff: 56a72c23 (report resolved dependency versions in the
POM report — DependencyWriter/DependencyWriterSpec) and 512c1068
(configure the JVM test task in kmp-module).

Reviewer notes (non-blocking)

A pre-PR review pass (spine-code-review, kotlin-engineer, review-docs) returned
APPROVE WITH CHANGES with no must-fix items. The should-fixes all concern the
earlier 56a72c23 commit and are left for the author's discretion:

• DependencyWriter.kt:209 — the generic catch (e: Exception) in the
  resolve-all-configurations loop should rethrow CancellationException first.
• DependencyWriter.kt:178 — inline the single-use moduleDependency local
  (type-name-as-variable-name).
• DependencyWriter.kt:165 KDoc — "a version … which carries no explicit
  version" reads as a version carrying a version; reword to "a dependency
  managed by a BOM, which declares no explicit version".
• .agents/tasks/pom-resolved-versions.md — stale branch: master and
  unchecked plan boxes despite status: in-review (task files are deleted on
  merge per AGENTS.md).

🤖 Generated with Claude Code

[alexander-yevsyukov]

Superseding this PR: the Gradle 9.6 deprecations it targets were already addressed on master by #719 (merged 2026-06-30), which this branch predated.

#719 is the more complete fix — it deletes the deprecated jacoco-kmm-jvm.gradle.kts / jacoco-kotlin-jvm.gradle.kts scripts, whereas this branch only patched them (merging it would re-introduce the removed files). For jvm-module.gradle.kts the two branches are byte-identical; ProjectMetadata.kt and uber-jar-module.gradle.kts differ only cosmetically. No unique, non-regressive changes remain here.

One follow-up worth noting: this branch's discovery run surfaced a third deprecation not in #719's tracking note — Kover 0.9.8's "Using a Project object as a dependency notation" from PrepareKover.kt, which appears during the buildSrc precompiled-script-plugin accessor generation (#719 measured only > Configure project :). If that's worth tracking, it can be added to .agents/tasks/gradle-9.6-deprecations.md on master in a small standalone change.

Closing as superseded by #719.