Revisit Early stopping

Early stopping and current validity check reporting is confusing.

For example, this deepseek run has 1.9 second TTFT. The validity checker still reports it as invalid because early stopping uses some different threshold as a validity criterion. This is not communicated clearly. Please refer to the example below.

Server Scenario:

+--------------------------------------+-------------+-----------+----------+-------------------------+----------------------------------\

--+------------------+------------------+

| System Name | Benchmark | Setting | Valid? | Per-query time usage | Metric Name \

| Measured Value | Avg. Power (W) |

+======================================+=============+===========+==========+=========================+==================================\

==+==================+==================+

| vSYS-422GA-NBRT-B200-SXM-180GBx8_TRT | deepseek-r1 | cp990 | INVALID | TTFT: 99.6%, TPOT: 75.8 | result_completed_tokens_per_secon\

d | 12331.70 | N/A |

+--------------------------------------+-------------+-----------+----------+-------------------------+----------------------------------\

--+------------------+------------------+

• Note: 'Per-query time usage' is the measured 99th-percentile latency divided by the requested server latency. This value should not e\

xceed 100% for a 'VALID' result.

No files or tests are named. Start by locating the early-stopping implementation and validity-check reporting, then reproduce the deepseek-r1 example to compare their thresholds and messages. Done should include agreed behavior and clear reporting for cases where early stopping and validity criteria differ.