fix: normalise non-native AbortSignal for Node 24+ compatibility

[bkaney]

Problem

Closes #204

On Node 24+, undici's Request constructor enforces a strict instanceof AbortSignal check. Polyfill libraries like node-abort-controller create their own AbortSignal class that is not the native one, causing a TypeError at request-build time:

TypeError: RequestInit: Expected signal ("AbortSignal {...}") to be an instance of AbortSignal.

The crash site was http-client.ts where the incoming signal was assigned directly to RequestInit and forwarded to new Request(url, requestInit):

if (options.signal) requestInit.signal = options.signal; // ← non-native signal
return new Request(url, requestInit);                     // ← undici rejects on Node 24+

Fix

Introduce a normalizeSignal() helper that bridges any foreign signal to a native AbortController/AbortSignal pair before it reaches new Request():

function normalizeSignal(signal: AbortSignal): AbortSignal {
  if (signal instanceof AbortSignal) return signal; // native → no-op

  const controller = new AbortController();
  if (signal.aborted) {
    controller.abort(signal.reason);          // already aborted → propagate immediately
  } else {
    signal.addEventListener('abort', () => controller.abort(signal.reason), { once: true });
  }
  return controller.signal;
}

Properties of the fix:

• ✅ Zero-cost for the happy path — native signals pass through unchanged
• ✅ Correctly propagates an already-aborted signal
• ✅ Correctly forwards a live abort event from the foreign signal
• ✅ No new dependencies — uses only built-in globals available on all supported Node versions

Tests

Two regression tests added under describe('AbortSignal compatibility') in test/client.test.ts using a FakeAbortSignal (a custom EventTarget subclass that mirrors node-abort-controller's pattern):

1. Non-native signal on a live request — verifies the request completes successfully
2. Already-aborted non-native signal — verifies the request is correctly rejected