TRANSACTION_TIMEOUT produces both a LibsqlError and a (uncatchable?) ResponseError

When I hit transaction timeouts, batch() rejects with a LibsqlError that looks something like:

{
  "code": "TRANSACTION_TIMEOUT",
  "name": "LibsqlError",
  "message": "TRANSACTION_TIMEOUT: Transaction timed out"
}

However, while I'm in the middle of sending that error off to an SNS reporting topic (an async call), Node appears to discover an unhandled Promise rejection ResponseError and bails (meaning I get no error reporting at all):

2023-11-06T03:29:49.648Z	4ecc5eff-6470-4a1a-989e-bb9f2d859822	ERROR	Unhandled Promise Rejection 	
{
    "errorType": "Runtime.UnhandledPromiseRejection",
    "errorMessage": "ResponseError: Transaction timed out",
    "reason": {
        "errorType": "ResponseError",
        "errorMessage": "Transaction timed out",
        "code": "TRANSACTION_TIMEOUT",
        "name": "ResponseError",
        "proto": {
            "message": "Transaction timed out",
            "code": "TRANSACTION_TIMEOUT"
        }
    },
    "promise": {},
    "stack": [
        "Runtime.UnhandledPromiseRejection: ResponseError: Transaction timed out",
        "    at process.<anonymous> (file:///var/runtime/index.mjs:1276:17)",
        "    at process.emit (node:events:517:28)",
        "    at emit (node:internal/process/promises:149:20)",
        "    at processPromiseRejections (node:internal/process/promises:283:27)",
        "    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)"
    ]
}

Is a transaction timeout causing a ResponseError rejection that the client can't catch?

Start by reproducing a transaction timeout through batch() and tracing the resulting LibsqlError and ResponseError Promise rejections in the TypeScript client. Done means determining whether the ResponseError is an unhandled rejection and making the timeout produce only a catchable error, with regression coverage for the reported behavior.