[wshlavacek]

Removes BIOMD0000000338|klu_vs_dense from parity_checks/nightly/flaky.json. #1338 added it, saying the dense reference depends on the runner's CPU. On Linux it does not. The full measurements are in this comment on #1304.

Why it is not flaky

#1338's evidence was a PASS run on an EPYC 9V45 and an EXCEPTION run on a Xeon 8370C. Those two runs fall on either side of #1302. Across all eight runs on either side, the outcome follows the commit, and the same CPU model gives both outcomes:

	runs	CPUs	klu_vs_dense
before #1302 (main at b543f7b)	3	EPYC 9V45, 7763, 9V74	PASS
after #1302 (main at aedadd8 or later)	5	EPYC 9V74, 7763, Xeon 8370C	EXCEPTION, CV_CONV_FAILURE at t = 0.72

#1321's per-run timeout is ruled out. The passing EPYC 9V74 run already had it, and the code klu_vs_dense runs through is identical there and in a failing run on the same CPU model.

Why remove the entry

• The committed baseline records the case as EXCEPTION (nightly: re-baseline differential from the scheduled run on main at 9a26f5b5 (#1302, #1304) #1367), and that is what keeps it from alerting. The entry adds nothing to that.
• Its text gives the wrong cause.
• Once a fix for BIOMD0000000338 and 339: KLU and the dense solver take different branches past a step-size collapse (Fg 311 on KLU, 0.73 on dense and libRoadRunner) #1304 brings the case back to PASS and the baseline follows, the entry would keep a later flip from alerting.

Checked

• Replayed verdicts.py diff with and without the entry:
  • differential: seven reviewed PRs as one merge (#1316-#1320, #1322, #1323) #1384's nightly (run 40904665252) against main's baseline: 0 alerts either way.
  • The same night against the previous night (run 40899240805): 0 alerts either way.
  • The case is EXCEPTION in all three files, so it is not listed.
• parity_checks/tests/test_nightly_verdicts.py: 75 passed, including the committed-file format check, which needs every listed suite to keep at least one case. differential had only this one, so its key goes too.
• flaky.json is outside the nightly's pull-request path filter, so this pull request does not re-run the sweep.

Refs #1304. That issue stays open: the dense quotient's failure on Linux after #1302 is still unexplained.