Binary parameters with length 0 or NaN are rejected by the server since 20.3.0 #1812

Software versions

• Tedious: 20.3.0 – 20.3.4 (20.2.3 behaves differently)
• SQL Server: Azure SQL Edge (local)
• Node.js: 24.x

Additional Libraries Used and Versions
None; this is tedious alone. Found while reviewing #1810 / #1811.

Table schema
None needed.

Connection configuration
Nothing special: default authentication, trustServerCertificate: true.

Problem description
A Binary parameter with an explicit length: 0 or length: NaN worked in 20.2.3 and is rejected by the server since 20.3.0:

const req = new Request('select @p as p', console.log)
req.addParameter('p', TYPES.Binary, Buffer.from('JP'), { length: 0 }) // or { length: NaN }
connection.execSql(req)

This may well be intended, so I'm reporting it to check rather than asking for it to be reverted. In 20.2.3, RpcRequestPayload only used an explicit length if it was truthy (if (parameter.length) … else type.resolveLength(parameter)). Binary.resolveLength ignores parameter.length and resolves from the value, so 0/NaN were silently replaced by the value's length. Every other type's resolveLength returns an explicit length as-is, so with 20.2.3 length: 0 was already rejected for VarBinary, Char, NChar, VarChar and NVarChar, and NaN for Char and NChar. Since #1774, resolveParameter lets any explicit length win ("including an explicit zero", data-type.ts#L153-L156), so Binary now behaves like the rest.

Expected behavior
Either 20.2.3's behaviour for Binary, or (probably better, and for every type) a clear client-side error for a length the server can't accept.

Actual behavior
The request is sent with a TYPE_INFO length of 0, and the server rejects it.

Error message/stack trace

RequestError: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 3 ("@p"): Data type 0xAD has an invalid data length or metadata length.

Any other details that can be helpful
Possible directions, for whichever you prefer:

1. Treat this as intended (consistent with the other types) and close this issue.
2. Reject a non-positive or non-numeric explicit length in resolveParameter with an InputError, in line with fix: wrap bulk load serialization errors in InputError #1772, so callers get a clear error instead of the server's generic RPC message, for all types.
3. Restore the 20.2.3 fallback (resolve a falsy length from the value). That would make the other types lenient too, which seems like a bigger behaviour change than the regression.

It fails loudly rather than sending wrong data, so it's low priority.