refactor(build): convert jacoco.gradle Kotlin DSL

[david-allison]

Note

Assisted-by: Claude Opus 4.7 - all

Fixes

• Part of architecture: move from .gradle to .gradle.kts (Kotlin DSL) for build scripts/logic #20910

Approach

Asked Claude to do a 1:1 conversion.

Claude: explanation of differences

Moved testCoverage into build.gradle because AGP types (CommonExtension) aren't on the applied .kts script's compile classpath.

The 1:1 conversion preserves the Groovy structure where Kotlin permits. Two unavoidable deviations from the original:
- sourceDirectories.from = X → sourceDirectories.setFrom(X) — Groovy's .from = X is metaprogramming that calls setFrom.
ConfigurableFileCollection.from exposes only a getter (returning Set<Object>) in Java, so Kotlin has no = setter to bind to. Kotlin DSL's lazy-property assignment only applies to Property<T>, not file collections.
- new GradleScriptException(msg, null) → GradleException(msg) — In this Gradle/Kotlin version the second parameter rejects null at compile time GradleException is GradleScriptException's parent and produces an equivalent build failure with a null cause.

How Has This Been Tested?

Trusting CI on this one.
I ran :AnkiDroid:jacocoUnitTestReport and :AnkiDroid:jacocoAndroidTestReport` and fixed configuration cache issues

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[david-allison]

Given the diff, I'd rather break git bisect on this commit, and perform a rename.

Reviewer's choice, but we should be consistent with the remaining files.

[mikehardy]

"the proof is in the pudding" --> https://app.codecov.io/gh/ankidroid/Anki-Android/pull/20911

LGTM, is readable enough

You bisect more than most, I'm not concerned with the diff really, I think over time the ability to read this diff will have zero value (who exactly is ever going to read it? and why?), but bisect has value (especially around a release) so I would lean somewhat heavily towards preserving bisect as the "has value" choice.

But having said that, leaving to you to merge however you see fit - at will

[david-allison]

Reading the diff is temporary, keeping git history is worthwhile breaking the build for