Publish scip-kotlin-analysis with JetBrains-only jars bundled (#1070)

* Publish scip-kotlin-analysis with JetBrains-only jars bundled

scip-java 0.14.0 depends on scip-kotlin-analysis, which was never
published, so org.scip-code:scip-java:0.14.0 does not resolve from
Maven Central and the release-cli job failed.

The Analysis API *-for-ide artifacts and the IntelliJ coroutines fork
only exist on JetBrains' repository, so they are merged into the
scip-kotlin-analysis jar and the published POM references only Maven
Central artifacts.

kotlin-compiler-common-for-ide is dropped: kotlin-compiler 2.4.0 already
contains the decompiler classes it was added for, and kotlin-compiler
already won every class the two jars share on the classpath.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1aac9-e7b5-72af-ad93-8f4a2a058fac
Co-authored-by: Amp <amp@ampcode.com>

* Build the release launcher with cs bootstrap --assembly

The --standalone launcher keeps dependency jars nested inside the
launcher jar, so the Kotlin compiler cannot locate
extensions/compiler-cli-root.xml on disk and Kotlin indexing fails with
"Unable to find extension point configuration". An --assembly
launcher merges the dependencies into a single jar, which works.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1aac9-e7b5-72af-ad93-8f4a2a058fac
Co-authored-by: Amp <amp@ampcode.com>

---------

Co-authored-by: Amp <amp@ampcode.com>

Keep Kotlin compile configs of composite builds apart (#1065)

The Gradle plugin named each Kotlin config file after the sanitized task
path. Task paths are only unique within one build, so the root build and
an included build both wrote -compileKotlin.txt and the later one
replaced the earlier, dropping its sources from the index. Sanitizing
also mapped :a-b:compileKotlin and 🅰️b:compileKotlin to the same name.

Name the file after a hash of the build's root directory and the task
path instead.

Use sbt-sourcegraph 0.4.3 for sbt versions before 1.9

sbt-sourcegraph 0.4.4 is published to Maven Central only under the
Maven-compatible file names that sbt 1.9 introduced
(sbt-sourcegraph_2.12_1.0-0.4.4.pom). Earlier sbt versions look for
the legacy name (sbt-sourcegraph-0.4.4.pom) and fail with
"Error downloading com.sourcegraph:sbt-sourcegraph ... 0.4.4" while
loading the project, so 0.12.x cannot index sbt 1.2 to 1.8 projects
that 0.11.x indexed. Inject 0.4.3, the version 0.11.x used, for those
sbt versions, and keep 0.4.4 for sbt 1.9 and later.

Use sbt-sourcegraph 0.4.3 for sbt versions before 1.9

sbt-sourcegraph 0.4.4 is published to Maven Central only under the
Maven-compatible file names that sbt 1.9 introduced
(sbt-sourcegraph_2.12_1.0-0.4.4.pom). Earlier sbt versions look for
the legacy name (sbt-sourcegraph-0.4.4.pom) and fail with
"Error downloading com.sourcegraph:sbt-sourcegraph ... 0.4.4" while
loading the project, so 0.12.x cannot index sbt 1.2 to 1.8 projects
that 0.11.x indexed. Inject 0.4.3, the version 0.11.x used, for those
sbt versions, and keep 0.4.4 for sbt 1.9 and later.

Call the Maven plugin by its coordinates in CI

GitHub's ubuntu-24.04 runners now ship Maven 3.10.0, which loads Maven
Central's auto-discovered prefix list and no longer resolves the
`sourcegraph:` plugin prefix to the local snapshot of
com.sourcegraph:maven-plugin, so the Maven tests failed with "No plugin
found for prefix 'sourcegraph'". Maven 3.9.1, as in the Docker image,
still resolves the prefix. Full coordinates work with both.

Co-authored-by: Amp <amp@ampcode.com>
Amp-Thread-ID: https://ampcode.com/threads/T-01a17c9a-c119-74c0-aa28-12519e886e5b

Make Docker image JVMs trust the patched system CA store (#1042)

Ubuntu's ca-certificates 20260816ubuntu0.26.04.1 distrusts emSign ECC
Root CA - G3 after the eMudhra intermediate CA compromise, but the JDKs
in the image use their own cacerts, and the native cs launcher embeds
GraalVM's trust store, so they still accepted the compromised chains.

- Upgrade ca-certificates explicitly instead of keeping the base image's
  copy.
- Generate a Java trust store from the system store with p11-kit and
  link the cacerts of the base JDK and the pre-installed coursier JDKs to
  it. Point JAVA_TOOL_OPTIONS at it as well so JDKs downloaded at runtime
  use it too.
- Install only the JVM coursier launcher, so cs uses that trust store.

Amp-Thread-ID: https://ampcode.com/threads/T-01a16042-0485-742e-abfb-a9aa55a01ecb

Co-authored-by: Amp <amp@ampcode.com>

Fix duplicate documents in Bazel index aggregation (#972)

Support centrally declared repositories in Gradle plugin (#969)

ci: fix malformed cli artifact upload command (#859)

ci: scope runner.temp to steps that use it (#858)