…ix UNKNOWN ordering

The flaky check runs with `--max-failures 5`. When a test legitimately failed
five times, `clickhouse-test` raised `StopTesting` with the default
`STOP_TESTING_EXIT_CODE` (2) - the same code used when the server actually dies.
The job side (`functional_tests_results.py`) then reported a generic "Server
died" leaf and demoted every real failure to `UNKNOWN`, hiding which test
actually failed even though the server was perfectly alive.

Give the `--max-failures` / `--max-failures-chain` stop its own exit code
(`MAX_FAILURES_EXIT_CODE = 4`), distinct from server death and the global time
limit. The parent detects the max-failures stop (shared failure counter) and
re-raises with the new code; the worker-side raises carry it for sequential
runs. The job side reports it as "Too many test failures" and keeps the failing
tests as FAIL (real, already-attributed failures) instead of demoting them.

Also fix the HTML report ordering: `getStatusPriority` in `json.html` had no
branch for UNKNOWN, so it fell through to the lowest priority and sorted below
all the OK rows (fail > ok > unknown). Rank UNKNOWN right under the errors and
failures so the rows whose real result was lost are visible at the top.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

In a parallel run the worker that reaches `--max-failures` or
`--max-failures-chain` raises `StopTesting` with `MAX_FAILURES_EXIT_CODE`
inside its own process, so that exception never reaches the parent. The
parent reconstructed the code only from the shared total-failure counter,
so the `--max-failures-chain` path (and `--max-failures 0`) fell through.

Worse, reproducing it shows both parallel paths exited 143, not the default
2: the worker's `stop_tests()` does `killpg(SIGTERM)` over the whole process
group, killing the parent before it can re-raise with the right code. 143
(`128 + SIGTERM`) is an aborted-run code, so the job side still reported
"Server died" and demoted the real failures to `UNKNOWN`. The global time
limit path avoids this because the parent initiates it and masks SIGTERM
first.

Fix:
- Carry the worker's intended exit code to the parent through a shared
  `stop_exit_code` value (set before `stop_testing`); the parent re-raises
  with it. This covers both `--max-failures` and `--max-failures-chain`.
- The max-failures / chain raises no longer call `stop_tests()`, so they do
  not SIGTERM the parent. The parent masks SIGTERM and terminates the workers
  in an orderly way, exactly like the time limit path. Server death keeps
  `stop_tests()` (still reported as "Server died").
- A sibling worker that only observes `stop_testing` now breaks quietly when
  concurrent instead of calling `stop_tests()`, mirroring the time limit
  handling.

Add focused coverage in `ci/tests`: a unit test that `MAX_FAILURES_EXIT_CODE`
maps to a "Too many test failures" leaf and keeps the failures as `FAIL`
(contrasted with the aborted-run code that demotes to `UNKNOWN`), and an
end-to-end test that a parallel run exits with `MAX_FAILURES_EXIT_CODE` for
both the chain-limit and total-limit paths.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>