fix(tools): bound memory forget requests - #1451

supermemoryai#1451 bounded `DELETE /v4/memories` with a 30s abort, but the two signals
were selected between with `??`:

    signal: options?.signal ?? AbortSignal.timeout(FETCH_TIMEOUT_MS)

so they were mutually exclusive. Any caller who passed a cancellation
signal silently dropped the timeout and the request went unbounded
again - exactly the hang supermemoryai#1451 set out to remove - and there was no way
to ask for both through the API. No production call site passes options
today (ai-sdk.ts and openai/tools.ts both omit it), so this was latent.

Composes the two with `AbortSignal.any` instead, so a caller signal
cancels the request and the 30s ceiling still applies. The timeout
signal is built once and reused for the bare case.

Verified against a server that never responds: before this change the
caller-signal path hangs indefinitely; after it, it rejects with
TimeoutError at the deadline, an early caller abort still wins with
AbortError, and an already-aborted signal rejects immediately.

Test coverage in tool-operations.test.ts replaces the case that asserted
the old select-one behaviour with four: caller abort propagates to the
composed signal, the timeout still fires while the caller signal stays
live, an already-aborted caller signal is forwarded, and an options
object without a signal still gets the timeout.

supermemoryai#1451 bounded `DELETE /v4/memories` with a 30s abort, but the two signals
were selected between with `??`:

    signal: options?.signal ?? AbortSignal.timeout(FETCH_TIMEOUT_MS)

so they were mutually exclusive. Any caller who passed a cancellation
signal silently dropped the timeout and the request went unbounded
again - exactly the hang supermemoryai#1451 set out to remove - and there was no way
to ask for both through the API. No production call site passes options
today (ai-sdk.ts and openai/tools.ts both omit it), so this was latent.

Composes the two with `AbortSignal.any` instead, so a caller signal
cancels the request and the 30s ceiling still applies. The timeout
signal is built once and reused for the bare case.

Verified against a server that never responds: before this change the
caller-signal path hangs indefinitely; after it, it rejects with
TimeoutError at the deadline, an early caller abort still wins with
AbortError, and an already-aborted signal rejects immediately.

tool-operations.test.ts replaces the case that asserted the old
select-one behaviour with five: the caller signal is composed rather
than substituted and its abort reason reaches the request, the timeout
still fires while the caller signal stays open, an already-aborted
caller signal is forwarded, the bare path still gets the 30s timeout
signal itself, and an aborted fetch surfaces to the caller.

Each case was checked against mutants of the fix - dropping the timeout
from AbortSignal.any, composing with a signal that never fires, reverting
to ??, and shortening the timeout - and every mutant fails at least one
of them.

`forgetMemoryRequest` combined the caller's signal and the 30s abort with
`??`, making them mutually exclusive. Passing a cancellation signal removed
the timeout, so a hung `DELETE /v4/memories` could wedge the tool call again
— the exact condition supermemoryai#1451 set out to remove. There was also no way for a
caller to ask for both cancellation and a timeout.

Compose the two with `AbortSignal.any` instead of choosing between them.
`AbortSignal.any` is available in Node 20.3+, Bun and workerd.

No production call site passes `options` today (`ai-sdk.ts` and
`openai/tools.ts` both omit it), so this was latent rather than live.

The existing test asserted the buggy behaviour (`init.signal` being the
caller's own signal), so it is replaced by two tests that pin the composed
semantics: aborting the caller aborts the request, and the timeout leg still
aborts the request on its own. Both fail against the previous implementation.

Fixes supermemoryai#1549