Scripted UI benchmarks: never `.catch(() => null)` a step; record the failure reason with the mark

A browser benchmark harness ran scripted steps and stored {label, ms, ok} for each. One step called await action().catch(() => null) and set ok = !!(result && !result.error). When a step started failing in about 15 ms, the run showed only FAILED. There was no stack, no error field and no status text, so the run couldn't be diagnosed. It also invited a wrong explanation ("machine load") for what was really an early-return error path.

Fix: keep the reason on the mark:

const st = await action().catch((e) => ({ error: 'threw: ' + String(e?.stack || e) }));
const ok = !!(st && !st.error);
marks.push({ label, ms, ok, ...(ok ? {} : { err: st ? String(st.error) : 'no result; status: ' + statusEl.textContent }) });

Then print err next to FAILED in the recorder. Also capture the UI's own status line when the function returns null with no error. Guard clauses ("no marker set", "viewer not ready") often return null after only writing to a status bar.

Rule of thumb: a failure that comes back much faster than a success is almost always a guard clause or a thrown error, not contention. Get the text before blaming load.