fix multi-blob insert queries (fixes #394)

[HeyyCzer]

Fix: Multiple non-null BLOB parameters causing silent failure or "Invalid BLOB handle" error

Problem

When a single SQL statement contained 2 or more non-null BLOB parameters, one of two failures occurred:

• Silent failure: the INSERT callback fired without error, commit() succeeded, but the row was never written to the database
• GDSCode 335544834 ("Cursor is not open") when RETURNING was used
• "Invalid BLOB handle" on protocol v11+ connections

Root Cause

Two compounding issues in PrepareParams inside executeStatement (lib/wire/connection.js):

1. Concurrent BLOB uploads: parameters were processed in a synchronous for loop using a countdown (wait/done) pattern. All BLOB parameters fired createBlob2 simultaneously, interleaving op_create_blob2 requests before any responses were received, corrupting the _queue response ordering.

2. Deferred closeBlob: closeBlob used _queueEvent(callback, defer=true), which on protocol >= v11 sends the op_close_blob packet with the lazy-send flag and calls the callback immediately without waiting for server confirmation. Even after fixing the loop, the next BLOB's op_create_blob2 was sent before the server had finished processing the previous blob's close, resulting in "Invalid BLOB handle".

Fix

1. Replaced the concurrent for loop with a sequential step(i) recursive function — each parameter is fully processed before the next one starts.

2. Added a defer parameter to closeBlob (default true to preserve existing behavior). Inside putBlobData, closeBlob is called with defer=false, forcing the server to acknowledge the close before the next BLOB upload begins.

Impact

• Fixes INSERT with 2+ non-null BLOB parameters
• Fixes INSERT ... RETURNING with multiple BLOBs
• No behavioral change for SELECT queries or single-BLOB statements