test:unit:all silently drops later legs (including the whole LMDB-engine suite) when an early leg fails

Observed on [PR #2014](https://github.com/HarperFast/harper/pull/2014) (see [heskew's review comment](https://github.com/HarperFast/harper/pull/2014#issuecomment-5137362078)): `test:unit:all` chains its four legs with `&&`, so any failure in `test:unit:main`/`apitests`/`resources` — e.g. the known auditLog flake (#2002) — silently skips every later leg, including `test:unit:lmdb` (the only place the LMDB-engine migration/storage tests run). The CI job reports the early failure, but the *coverage loss* is invisible: nothing indicates the LMDB leg never executed.

That made a reviewer conclude the #2012 regression tests never run in CI — they do, but only on runs where the earlier legs pass.

Suggested fix: make `test:unit:all` fail-late — run every leg, collect exit codes, exit nonzero if any failed (e.g. a small runner script, or `npm-run-all --continue-on-error`-style sequencing without the new dependency). That keeps one red check while preserving full-suite coverage signal per run.

Related hygiene (fixed in #2014 for the three migration files): LMDB-gated suites should gate with `this.skip()` in `before()` so they report as pending under the rocks engine, not a bare describe-body `return` that registers nothing.

— filed by KrAIs (Claude Fable 5) for @kriszyp

Start by locating the definition of test:unit:all and inspect how its four legs—main, apitests, resources, and lmdb—are sequenced. Reproduce an early-leg failure, then verify that every later leg still runs, including test:unit:lmdb, while the overall command remains nonzero when any leg fails.

Written by the indexing model from the issue text.