test(bmdb): accept the three changed BMDB results

[jcschaff]

The BMDB nightly has failed every night since 2026-08-31. This accepts the three deviations
in the 09-07 run (34094676265):

model	baseline	this run
BIOMD0000000547	SOLVER_FAILURE	MATH_GENERATION_FAILURE
BIOMD0000000613	DIVIDE_BY_ZERO	MATH_GENERATION_FAILURE
BIOMD0000001065	SOLVER_FAILURE	PASSED

None is a regression. No model went from passing to failing; the two that changed were
already failing and now fail at an earlier phase, and one that was failing now passes.
Totals moved the right way: 914 → 915 passes, 147 → 146 failures.

Verified, both directions

Against that night's own exec_summary.ndjson rather than by reasoning about it:

• old baseline → FAIL: 3 changed, exit 1 — reproduces the nightly failure locally
• new baseline → PASS: no changes against the documented baseline, exit 0

Only the three rows are re-serialized; the other 1179 are untouched byte for byte, so the
diff is three lines.

A second file had to move with it

bioModelsNetInfo.xml carries a Supported flag per BioModels entry, and
BioModelsNetInfoTest keeps it honest against this baseline — it failed CI on the first
commit, which is the check doing its job. Two flags moved:

BIOMD0000000547  Supported true -> false
BIOMD0000000613  Supported true -> false

That is the right consequence, not a side effect. Supported means VCell can import the
model, so the test derives it from whether the recorded failure is import-blocking.
SOLVER_FAILURE and DIVIDE_BY_ZERO are not — the model imports and then fails to solve —
while MATH_GENERATION_FAILURE is, and that is what both now report. BIOMD0000001065
needed no change: it went FAIL → PASS, and SOLVER_FAILURE was already non-blocking, so
its flag was true either way.

Regenerated with the command the test prints, so the file is byte-for-byte apart from the
two attributes, and stays CRLF.

What this does not fix — see #2077

Accepting a baseline does not stop these cases moving. Over the last seven nightlies four
different models deviated, in rotation:

model	behaviour
1065	deviated (PASSED) on six of seven nights; matched its FAIL baseline once, on 09-06
547	MATH_GENERATION_FAILURE on 09-04/05/06/07, SOLVER_FAILURE before
613	MATH_GENERATION_FAILURE on 09-03/05/06/07, DIVIDE_BY_ZERO on 09-04
457	flipped PASSED → SOLVER_FAILURE on 09-05 only, and came back

The 08-30 pass and 08-31 failure are on the same commit, which rules out a code change.

Two are numerically borderline and probably always will be — 1065 fails on
pow(u,v) and u=-0.000000<0 with EN_0_0 = -0.000000, and 547 on
At t = 8.09814e-18, mxstep steps taken.

613 is not numerical, and that is what #2077 is about: it alternates between
divide by zero '(M_initConc / OC_initConc)' raised while writing the solver input and
Initial condition for variable 'M' references variable 'L' raised during math generation
— the same initial condition, two phases apart, same input and same code. That reads as
ordering-dependent math generation.

So expect this gate to fail again on a night when one of these lands the other way. That is
the gate working, not a new problem.

🤖 Generated with Claude Code

https://claude.ai/code/session_019HAnpFxkzf9LmxBayDSANf