`javatest` with uncontrolled output can run free and silently starve disk usage on Mac

### Description of the bug:

I recently was debugging https://github.com/google/jni-bind/issues/414 and to do so I created a malicious test that mimics the leaking behaviour described in the bug.

The test basically just creates local references to Java Strings and doesn't release them. The code is JNI code run from a `java_test`. I'm running on a Macbook pro (m4) with ~1TB of disk space (750 GB free).

I put the malicious behaviour on a PR so you can reproduce:

https://github.com/google/jni-bind/pull/417
`bazel run //javatests/com/jnibind/test:StringTest`

The test spews output to the console and crashing the process does not actually stop the Java code from running. Surprisingly, even killing Java with pkill -9 doesn't always seem to work properly.

After some time, the code will continue writing log output to the System files eventually consuming all disk space. At this point it quickly becomes difficult to diagnose because the tools you need can't be downloaded (and your computer will start to act unstable). For me, the files were hidden in /System/ bazel logging. i.e.

`/System/Volumes/Data/private/tmp/_bazel_jamiesonpry....fastbuilg/testlogs/javatests/com/jnibind/test/StringTest/test.xml.log`

Basically the incessant logging is chewing through all disk space and making the computer unusable without stopping itself or being easily diagnosed for a regular mac user.

### Which category does this issue belong to?

Java Rules

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I put the malicious behaviour on a PR so you can reproduce:

https://github.com/google/jni-bind/pull/417
`bazel run //javatests/com/jnibind/test:StringTest`

### Which operating system are you running Bazel on?

Mac Sequoia 15.4.1

### What is the output of `bazel info release`?

release 7.0.2

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text
git@github.com:google/jni-bind.git
40b96579f87744eba9beb2146a7d76f5a4a1443d
```

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

### Have you found anything relevant by searching the web?

No

### Any other information, logs, or outputs that you want to share?

Start by reviewing PR 417 and running `bazel run //javatests/com/jnibind/test:StringTest` on macOS, then inspect the generated `test.xml.log` under the Bazel testlogs path. Trace why output continues after the test or Java process is terminated. Done means uncontrolled output no longer consumes disk indefinitely and the failure can be stopped or diagnosed safely.

Written by the indexing model from the issue text.