Cloned requests loose abort signal on GC

Bug Description

We noticed that AbortSignal.timeout() stopped working in our library with longer timeouts (in our case around 9s). Debugging showed that cloned (or constructor copied) requests won't respect an abort signal if GC has happened in between.

Reproducible By

Run with node --expose-gc

import { createServer } from 'node:http';

createServer(() => {
  // server that just hangs
}).listen(3000);

const ac = new AbortController();

let req = new Request('http://localhost:3000', {
  signal: ac.signal,
});

// cloned or copied requests (req = new Request(req)) breaks abort after gc
req = req.clone();

setTimeout(() => {
  // comment out the gc to make abort work
  global.gc();
  ac.abort();
  console.log('aborted, expecting immediate exception from fetch...');
});

await fetch(req);

Commenting out the cloning and/or the gc will make the code work as expected, i.e. the fetch call rejecting after abort.

Expected Behavior

A cloned request should respect it's abort signal even after a long time (or garbage collection).

Environment

macOS 15.3.1 (arm64), Node v23.4.0, v22.14.0, v20.18.0

Additional context

Debugging found that the difference before/after gc is that the "dependentControllerMap" entry for the signal is missing here

Start in deps/undici/src/lib/web/fetch/request.js at the dependentControllerMap entry mentioned in the issue, then run the provided reproduction with node --expose-gc. Verify behavior with cloning, copying, and garbage collection; done means a cloned Request retains its abort behavior and fetch rejects promptly after ac.abort().