fix(http): raw 'upgrade' + tls.TLSSocket + destroy no longer hangs the event loop (#5010)

[proggeramlug]

Fixes #5010.

Summary

test-http-upgrade-reconsume-stream regressed to a hang (exit 124 instead of 0) after #5001/#4973. The repro:

const tls = require('tls'); const http = require('http');
const server = http.createServer(common.mustNotCall());
server.on('upgrade', common.mustCall((request, socket, head) => {
  new tls.TLSSocket(socket);   // re-own the raw upgrade socket
  server.close();
  socket.destroy();
}));
server.listen(0, common.mustCall(() => {
  http.get({ port: server.address().port,
             headers: { Connection: 'Upgrade', Upgrade: 'websocket' } }).on('error', () => {});
}));

#4973 made a raw 'upgrade' hand the listener a real net.Socket adopted into perry-ext-net (adopt_upgraded_tcp_stream). Destroying it left a live handle pinning the loop. (The new tls.TLSSocket(socket) wrap named in the title is a red herring — the hang reproduces without it.)

Root cause — perry-stdlib/perry-ext-net duplicate-symbol ("twin") hazards

Both crates export the same #[no_mangle] net symbols; in a workspace/auto-optimize link the bundled-stdlib twin wins, and two things broke for the adopted socket:

1. socket.destroy() dynamic-dispatched through js_net_socket_destroy → bound to stdlib's twin → marked the socket destroyed in stdlib's empty registry while it stayed destroyed=false (alive) in ext-net's.
2. The socket's Close event sat in ext-net's own pending-event queue, which nothing reliably drained. For an http-only program perry-stdlib runs its own bundled net, so its external-net-pump arm never touches ext-net's queue, and the ext-net aux pump proved unreliable across link layouts — the behavior even flipped with unrelated code-size changes (link-order roulette).

Fix

• Give the destroy + queue-drain entry points distinct, twin-free #[no_mangle] symbols: js_ext_net_destroy_socket / js_ext_net_drain_pending (the original externs now delegate to them).
• Route the handle-dispatch destroy arm and the aux pump through those unique symbols.
• Drain ext-net's queue from the http-server pump (js_node_http_server_process_pending) — it runs every tick via external-http-server-pump and directly depends on perry-ext-net, so the call is a plain crate-path call to a symbol with no twin.

Verification

• Repro: exit 0, 10/10 runs and 8/8 on an independent rebuild (previously 0/8 — deterministically hung).
• No regression: normal http request/response exits 0; normal net echo data flow is unchanged (actually more reliable than pristine in spot checks). The pre-existing net-program close-hang is unrelated and out of scope.
• cargo test -p perry-ext-net: 8 passed.

Code-only — version bump + changelog left for the maintainer to fold at merge.