The coverage collection action is confusing

### Description of the bug:

Yesterday, I spent quite a bit of time figuring out why `bazel coverage` of just one test reported the test as finishing in 25 seconds but then Bazel stuck around for an extra 5 minutes before giving up and failing the build. There was zero progress information about what was happening. It was really confusing to see "passed test but failed build" without any sort of logs or error messages.

I looked at the perf profile and saw that there were two actions happening for the test, which I suspected, and the second action was exceeding its 5 minute time limit and timing out.

Then I had to resort to extracting an execution log of the build to see what was actually happening in that second action, because there were no other indications about it anywhere. In the execution log, I could see that this was the execution of `collect_coverage.sh`, which confusingly carries the same `TestRunner` mnemonic as the usual test actions. And from there, I could diagnose a problem in the script.

But this whole thing is too obscure. Bazel should expose the coverage action somehow so that it shows up as "running" in the UI in some way. And it'd probably be good to have a different mnemonic, and ways to tune its behavior.

### Which category does this issue belong to?

Core

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

Run a test in coverage mode with a large set of C++ dependencies so that there are many intermediate files to process and see a discrepancy between the test runtime and the Bazel runtime.

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

Linux, but it doesn't matter

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

7.6.1

### 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

```

### 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 response_

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

_No response_

Reproduce the discrepancy with bazel coverage and inspect the execution log, focusing on the collect_coverage.sh action and its TestRunner mnemonic. Trace how this action is surfaced while coverage runs; done means the coverage action has clear progress or running visibility, an unambiguous mnemonic, and documented behavior controls.

Written by the indexing model from the issue text.