fix(utils): keep batch rows when the SDK flags the envelope for a row error

[aa-blinov]

Summary

A batch call with one bad id returned a single opaque error and no rows, hiding the fact that the other ids had already been applied. batchV2 / batchV3 were checking the batch envelope's isSuccess first, and the SDK marks that envelope failed for per-row errors while filling the rows anyway. They now return the rows whenever rows came back — which is what their own JSDoc already promised.

Type of change

• feat
• fix
• docs
• chore
• test
• refactor
• ci

Linked issue

Checklist

• PR title follows Conventional Commits
• pnpm lint passes
• pnpm typecheck passes
• pnpm test passes
• New or changed code has tests
• Public-facing changes reflected in docs/ and skills/ (the batch section of skills/manage-bx24-template-mcp/adding-tools.md now warns against re-checking the envelope inside a tool)
• No unrelated changes
• No secrets in code, tests, or CI logs

Screenshots / logs

Before, against a live portal — two real tasks plus one nonexistent id:

b24_task_pause { taskId: [4193, 4191, 99999999] }
→ ERR  Действие над задачей не разрешено

Both real tasks were paused by that call. Nothing in the response says so.

After:

b24_task_start { taskId: [4193, 4191, 99999999] }
→ {"batch":true,"verb":"started","total":3,"ok":2,"failed":1,
   "results":[{"taskId":4193,"ok":true,"status":"3"},
              {"taskId":4191,"ok":true,"status":"3"},
              {"taskId":99999999,"ok":false,"error":"Действие над задачей не разрешено"}]}

Notes for reviewers

The mechanism, since it decides whether the fix is right rather than merely convenient:

AbstractBatch._createBatchArrayResult (SDK 1.3.0) builds the row array and then calls _addBatchErrorsIfAny, which copies each per-row error onto the envelope Result. Result.isSuccess is this._errors.size === 0. So under returnAjaxResult: true — which both helpers pass — the envelope is failed whenever any row failed, with every row still populated in getData(). Checking the envelope before reading rows therefore throws away exactly the partial-failure detail the batch tools are built to report, and isHaltOnError: false guarantees the other calls really did execute.

New contract: rows present → return them; no rows → throw. Transport throws are untouched, and per-row reporting through mapBatchRows is unchanged, so no tool needed editing.

One thing worth flagging honestly: the existing test does not throw for per-row failures (isHaltOnError: false semantics) mocked isSuccess: true alongside a failed row — a shape the SDK cannot produce. It passed throughout, which is why the bug survived. I left it in place (it still documents the intent) and added cases that pin the real shape, including the no-rows path that must keep throwing.

This affects every batch tool — the seven lifecycle verbs, checklist complete / renew / delete, rate, dependency add / remove, elapsed-time delete — so it's worth a close look at whether you'd rather have the envelope error also surfaced somewhere in the summary (e.g. a top-level envelopeError field) rather than only per row. I kept the payload shape unchanged on the grounds that the row errors already carry the same text.