skyway-core reports only the last error of a failed batch, hiding the root cause behind downstream decoys

When a multi-statement batch fails with a statement-level error (e.g. Msg 2627 unique-key violation, which terminates the statement but not the batch), SQL Server keeps executing the batch and node-mssql rejects with the LAST error. skyway-core's runner formats only `batchErr.message` and drops `precedingErrors`, so the logged failure can be a downstream decoy.

Real case: `V202608081200` failed CI with "INSERT conflicted with FK_EntityFieldValue_EntityField", but the actual first error was a UNIQUE KEY violation on `UQ_EntityField_EntityID_Sequence` three statements earlier. The FK error only existed because the batch kept running after the real one. Root-causing required a standalone repro of each statement; surfacing `precedingErrors` would have made it readable straight from the CI log. Forensics: https://github.com/MemberJunction/MJ/pull/3644#issuecomment-5228277027

Proposed: in the migration runner's error formatting (skyway.js around line 689 in the built output), when `err.precedingErrors` is non-empty, list every error in order and mark the first one as the likely root cause. Small change, high diagnostic leverage.

Inspect the migration runner's error formatting in skyway.js around line 689 in the built output, focusing on how batchErr.message is currently used and how precedingErrors is exposed. Verify the change with a failing multi-statement batch like the described migration case; done means the log lists every error in order and identifies the first as the likely root cause.

Written by the indexing model from the issue text.