REST fallback server-streaming reads can become non-cancellable and ignore the effective transport timeout, leaving Firestore reads stuck on batchGetDocuments

### Summary

I'm filing this in `googleapis/google-cloud-node` because the npm metadata for `google-gax` still points to archived repos (`googleapis/gax-nodejs` and `googleapis/google-cloud-node-core`). If there is now a better active home for the REST fallback transport layer, please route this there.

We reproduced a defect chain in Firestore REST fallback reads where a single silent server-streaming stall can become sticky:

1. Firestore `DocumentReference.get()` in REST mode uses server-streaming `batchGetDocuments`
2. the fallback transport deadline/timeout is not effectively enforced at the underlying fetch layer
3. the returned REST streaming object does not abort the underlying fetch when cancelled
4. this leaves the Firestore-side client checked out indefinitely if the stream never receives a first byte or terminal error

This reproduces in minimal form on:
- `google-gax@4.6.1` + `@google-cloud/firestore@7.11.6`
- `google-gax@5.0.6` + `@google-cloud/firestore@8.3.0`
- Node and Bun

### What we confirmed

Minimal repro without real Firestore credentials proves:
- fallback unary timeout/deadline can land in the ignored third arg
- fallback stream timeout/deadline can land in the ignored third arg
- returned REST stream `cancel()` does not abort the underlying fetch signal
- a silent stall can leave the Firestore-side client checked out indefinitely

In traced soak evidence from our production incident, the live stall point was:
- request sent
- fallback fetch dispatched
- no first response byte
- no stream end
- no client release

This is a runtime-agnostic REST fallback problem. Under a silent network stall, Node and Bun both showed the pending REST fallback fetch staying alive for at least 180s with no resolve/reject.

### Why this matters

A transient network blackhole can become sticky far beyond the original event:
- the read is not effectively transport-timed out
- the returned stream is not effectively transport-cancellable
- the Firestore layer keeps the client checked out

### Local mitigation we carry

We currently patch `google-gax@4.6.1` locally to:
- extract the effective timeout/deadline correctly
- enforce the transport timeout with an abort controller
- wire REST stream cancel to abort the underlying fetch

That mitigates the issue for our pinned stack, but the upstream gap appears to remain.

### Requested maintainer feedback

1. Is `googleapis/google-cloud-node` the correct active home for this report, or should it move elsewhere?
2. Is the fallback timeout/deadline argument ordering intended?
3. Is the returned REST stream cancel path expected to abort the underlying fetch?
4. If this belongs in a different repo/package now, could you route it?