Decide how the load harness should behave under `cargo test`

Split out of the change that drops benches from `just test` (see the PR that
closes this issue's sibling), which took the narrow fix and left the two
wider options undecided.

## What was measured

`just pre-commit` on a warm tree, timed per recipe:

| recipe | wall time |
| --- | --- |
| `fmt-check` | 1s |
| `clippy` | 0s |
| **`test`** | **1311s** |
| `clippy-loom` | 1s |
| `test-mirrors` | 1s |
| `test-doc` | 22s |

The same `test` recipe with `--all-targets` replaced by
`--lib --bins --tests --examples` takes **15s**. Test *execution* across all
23 binaries is 2.6s, so the 1311s is neither compilation nor the tests: it is
the benches running.

`benches/gauge.rs` and `benches/kernel_scan.rs` are criterion, which honours
`cargo test`'s `--test` flag and runs one iteration. `benches/kernel_load.rs`
has a hand-written `fn main() -> ExitCode` that does not, so `cargo test`
runs its full scenarios — `ci.yml`'s `test` job already says exactly this,
and already excludes benches for it.

## What was decided, and what was not

Decided: `just test` stops passing `--all-targets`, matching what CI's `test`
job already does. `clippy` keeps `--all-targets`, so the benches still have to
compile; `bench-smoke` and CI's `bench` job still run them.

Not decided, and the point of this issue:

1. **Should `kernel_load` honour `--test`?** An early return when `cargo test`
passes it would make `--all-targets` safe again everywhere, and would make
the harness behave like the two criterion benches beside it. Against: the
harness's `main` is an acceptance-run entry point (RFC 0006 §5.1, RFC 0007
§5-6, RFC 0014 §13.5), and a flag that silently does nothing is a shape
that can be reached by accident.
2. **Should `bench-internals` stay in `build_features`?** It is what pulls the
three benches into any `--all-targets` invocation. Dropping it from the
test recipe's feature set would also work, but `bench_support` is compiled
under it and `clippy` wants it, so the feature set would then differ
between the two recipes — a third feature set, and a third cargo cache.

Either would remove the trap rather than route around it. Which one depends
on what the harness's `main` is contracted to be, which is a judgment for the
maintainer rather than something the measurement settles.

## Why it is worth deciding rather than leaving

The trap is silent: `just test` reads as an ordinary test run, and nothing in
its name or output says a load harness is about to run for twenty minutes. It
was invoked repeatedly in one session before anyone noticed the cost.

Read benches/kernel_load.rs alongside benches/gauge.rs and benches/kernel_scan.rs, then compare the test and bench recipes in the justfile and ci.yml. Check the cited RFC sections for the harness contract and run the relevant cargo or just commands to confirm current behavior. Done means a maintainer-approved choice is recorded and the silent load-harness trap is addressed consistently.

Scritto dal modello di indicizzazione a partire dal testo della issue.