Diagnostics of the last accepted arc-length step this call took
(radius, retries, solves, chord length, determinant sign, stop
criterion), or None when it took none. With arc length the load
factor can decrease and repeat, so samples are ordered by their
sample index, never by load factor.
Only the samples this advance() call produced, one entry per recorder that recorded
at least one sample this call (every recorder samples every step today, so in practice
this is either empty — no step taken — or has one entry per recorder). This is the
results-storage plan's (docs/results-storage-indexeddb.md) recorderBatch, restated in
field names that match pysees's frozen ResultBlock protocol type
(src/app/types/resultsStorage.ts); the caller assigns blockIndex and packs data,
since neither concept exists on this side of the wasm boundary.
advance's result —{ done, stageComplete, stepsTaken, progressSnapshot, recorderBatch? }, minus the parts that are the worker/JS boundary's job (progressSnapshot's throttling,recorderBatch'sresponse_blocksbyte layout):load_factorhere is the raw signal those would be built from — for aStaticstage the integrator's load factor, for aTransientstage the elapsed time (TransientAnalysis::time), and for aModalstage always0.0(a single eigensolve has no comparable incremental progress scalar; readMode::frequencyfrom aModeShaperecorder's batch instead).error, once set, is sticky — later stages are not attempted, matching "a stage'sAnalysisErrorstops the sequence".