build: raise Gradle daemon heap to avoid intermittent CI OOM (#7151)

## Problem

The `build (25, saas)` CI job intermittently fails with:

```
The Daemon will expire immediately since the JVM garbage collector is thrashing.
The currently configured max heap space is '512 MiB' and the configured max metaspace is '384 MiB'.
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon has been stopped: since the JVM garbage collector is thrashing
```

`gradle.properties` never set `org.gradle.jvmargs`, so the daemon runs
on Gradle's 512 MiB default heap. The larger builds — the `saas` flavor
in particular, which compiles core + proprietary + saas — exhaust it
under `org.gradle.parallel=true`, and the daemon dies mid-build. It's
flaky (passes on re-run), which makes it a recurring, noisy CI failure.

## Fix

```properties
org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=1g
```

2 GiB heap + 1 GiB metaspace gives comfortable headroom on GitHub-hosted
runners and typical dev machines, well clear of the thrash point.
One-line, repo-wide config change.

## Verification

- `./gradlew help` starts the daemon cleanly with the new args (no
malformed-arg failure).
- The real signal is CI: this branch's `build (25, saas)` should stop
OOM-ing.

Split out from #7048 (Plan & Usage) since it's unrelated build
infrastructure.

gradle.properties

@@ -1,3 +1,9 @@
+# Gradle daemon heap. The default (512 MiB) is exhausted by the larger builds
+# (notably the saas flavor) under parallel execution, causing intermittent
+# "JVM garbage collector is thrashing" daemon deaths in CI. 2 GiB heap + 1 GiB
+# metaspace gives comfortable headroom on CI runners and typical dev machines.
+org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=1g
+
 # Enables parallel execution of tasks, allowing multiple tasks to run simultaneously
 org.gradle.parallel=true