bug(deno): adapter.test.ts isolation — handle-1 leaks across tests

[momics]

Summary

packages/iroh-http-deno/test/adapter.test.ts fails when run as a whole file: after the publicKeyVerify test closes its node (handle 1), the next test (serve — no pending ops remain after signal abort (regression #115)) emits an uncaught promise rejection IrohHandleError: node closed or not found (handle 1). Each test passes in isolation when run with --filter.

Reproduction

deno test --allow-all packages/iroh-http-deno/test/adapter.test.ts

Reproduces on a clean main (verified by stashing the #155 fix — same failure, 5 passed / 4 failed).

Suspect path

A background polling task started during the previous test (likely a connection-event loop attached to handle 1) survives node.close() and observes the closed handle in the next tick, surfacing as an uncaught promise.

Acceptance criteria

1. deno test --allow-all packages/iroh-http-deno/test/adapter.test.ts runs the full file with no failures.
2. Either the surviving polling loop is properly joined on close(), or the surviving promise is awaited / cancelled before the next test starts.

[momics]

Fixed in 8b55c71.

Root cause: not the polling-loop unhandled-rejection I first suspected. The Deno FFI dispatch and extern "C" symbols declared endpoint_handle as u32, but iroh-http-core::registry keys endpoints with slotmap, whose KeyData::as_ffi() packs (version << 32) | idx into a u64. Truncating to u32 stripped the version bits and reintroduced the ABA hazard the slotmap was specifically chosen to prevent.

Symptom across tests: a fresh node bound after a prior node was closed landed on slot index 0 with truncated handle 1. Cached state and stray callbacks from earlier tests then matched the new handle and raced with serve setup.

Fix widens endpoint_handle to u64 end-to-end (dispatch.rs, lib.rs, serve_registry.rs) and updates the Deno FFI symbol declarations + call sites to pass BigInt(endpointHandle).

Verified: deno test -A test/adapter.test.ts 9/9 pass; npm run ci green.