test(ext/node): regression test for empty buffer TLS write panic

[divybot]

Summary

Fixes the Deno Sandbox panic reported in #34404 by adding regression
coverage for the underlying crash.

Running:

import { Sandbox } from "@deno/sandbox";
await using sandbox = await Sandbox.create({});
await sandbox.sh`ls -lh /`;

panicked with:

thread 'main' panicked at ext\node\ops\tls_wrap.rs:2000:31:
called `Option::unwrap()` on a `None` value

Root cause

@deno/sandbox connects via npm:ws. The ws Sender batches frame
writes through the socket with cork() + write(header) +
write(data) + uncork(), and control / empty frames write
Buffer.alloc(0). That produces a node:tls writev containing a
zero-length chunk.

A zero-length ArrayBuffer has a null backing-store data pointer, so
v8::ArrayBuffer::data() returns None. The writev op used to do
ab.data().unwrap(), panicking on that None.

This was fixed in #33737, which changed the TLSWrap write ops to skip
chunks whose data() is None. The existing
tests/specs/node/tls_write_detached_buffer spec test covers the
detached-buffer trigger via direct handle calls. This PR adds
coverage for the empty / zero-length buffer trigger — the one
@deno/sandbox actually hits — through both direct handle calls and the
natural socket.write() + cork()/uncork() path.

Verification

• With the data() guard reverted to the old ab.data().unwrap(), the
  new test reproduces the original panic (called Option::unwrap() on a None value, same column :31).
• With the guard in place (current main), the test passes (ok).

No runtime code change — main already contains the fix; this locks it
in against regression for the reported scenario.

Closes denoland/orchid#241