fix: stop dropping blank update fields, and recover errors from binary requests

[rmyndharis]

Two cases where the node told the workflow less than the server knew.

A blank value in an update collection was dropped in silence

Template Update, Label Create or Update, and Automation Rule Update each skipped a blank name, body or replyText. The reason was sound: the server marks those fields non-empty, so forwarding a blank is a guaranteed 400 and skipping it saves a round trip. The result was not.

• A blank supplied alongside another field produced a successful partial update. The name looked updated and was not.
• A blank supplied on its own produced "At least one field must be provided to update", while a field was plainly sitting in the collection.

There is no reading under which a blank means something for these fields, so it is now refused by name, with a message saying how to leave the field unchanged. The three handlers share one helper (optionalNonBlank) rather than repeating the policy, because it has to stay consistent across them.

A blank header or footer on a template is deliberately untouched: those carry no non-empty validator, so clearing them is legitimate and still works. There is a test holding that line.

An error from a binary request lost its body

Operations that download media ask for an arraybuffer, so when the server answers with an error its JSON body arrives as raw bytes and the explanation never reaches the workflow.

Message > Get Media is where this matters. Its 404 covers five distinct situations (no media on the message, download disabled, payload over the storage cap, a URL-based send whose bytes are never stored, or the message not being in this gateway's history), and without the body the workflow sees only a status code.

The body is now decoded back onto the error before it is thrown, so the server's message survives into the NodeApiError. The decoding is fully guarded, so decorating an error can never itself throw, and it is applied only to binary requests: a normal JSON failure is passed through untouched, which a test asserts.

Verification

npm run build, npm run lint, 424 tests (up from 419), and the n8n Creator Portal scanner all pass; the committed dist/ matches source.

Both fixes were negative-controlled: with the fix reverted in the build output, the new tests fail, and they pass again once it is restored. The request-body conformance check (every body the node can build, validated against the server DTOs for undeclared fields, missing required fields, wrong types and bad enums) still reports zero problems.