assembleLibrariesRelease is the dominant step in analysis:detekt-custom,
taking ~8m 17s (56% of the job) in CI. Adding --parallel enables Gradle
to compile independent library modules concurrently within the same daemon
process (in-process workers sharing the 4Gi heap) rather than sequentially.

Unlike customDetektRules --parallel which spawns separate JVMs per task,
--parallel on assembleLibrariesRelease uses Gradle's built-in worker
infrastructure — no additional memory per concurrent task. The module
dependency graph has a natural fan-out: dd-sdk-android-internal and
dd-sdk-android-core must compile first, then 25+ feature and integration
modules can compile in parallel.

Move KUBERNETES_MEMORY_LIMIT from 13Gi to 32Gi in the root .gitlab-ci.yml,
matching datadog-android which uses the same limit on the same runner pool.

The higher limit is needed for jobs that run parallel JVM workers
(analysis:detekt-custom, test:debug). Setting it globally is simpler than
per-job overrides and has no scheduling cost since KUBERNETES_MEMORY_REQUEST
remains at 8Gi — the scheduler still only needs 8Gi free on the node.
Actual memory consumed per job is unchanged for jobs that don't use the
extra headroom.

Removes the now-redundant KUBERNETES_MEMORY_LIMIT: 32Gi override from
analysis:detekt-custom.

…--parallel

test:debug ran 5 separate ./gradlew --no-daemon invocations sequentially.
Each call pays the full Gradle startup and project configuration overhead
(~10-15s in CI × 4 extra calls = ~40-60s wasted). Consolidating into a
single invocation eliminates that redundancy.

--parallel --max-workers=4 lets Gradle run up to 4 modules' test tasks
concurrently. Each module forks its own test JVM (~768MB); 4 concurrent
test JVMs + 3Gi Gradle JVM ≈ 6Gi total — well within the 32Gi limit now
set globally.

Note: unlike assembleLibrariesRelease --parallel (in-process workers,
shared heap), test tasks fork separate JVMs. --max-workers=4 acts as the
memory safety valve, the same role it plays for customDetektRules.

…--parallel

test:kover ran 4 separate ./gradlew --no-daemon invocations for coverage
generation, paying ~33s of Gradle startup overhead across 3 extra calls.
Consolidating into a single invocation using the >- YAML folded scalar
eliminates that overhead (same fix applied to test:debug).

--parallel --max-workers=4 lets Gradle run up to 4 modules' koverXmlReport
tasks concurrently. koverXmlReportRelease forks a test JVM per module for
instrumented coverage tracking (~1.5-2GB each); 4 workers stay well within
the 32Gi global limit set in the previous commit.

test:kover is the current critical path of the test stage (~17m 55s avg)
now that test:debug has been reduced to ~7m 57s.