`resetTimeoutOnProgress` on low-level `request()` only works when `onprogress` is explicitly provided

I found a behavior in the TypeScript SDK that feels surprising when using the low-level request() API.

When I call request() with resetTimeoutOnProgress: true, I would expect incoming progress notifications to keep the request alive for timeout purposes. In practice, that only seems to happen when onprogress is explicitly provided in the request options.

The issue is not that I do not want to track progress. In my case, progress may already be consumed through lower-level transport features. The problem is that if onprogress is not explicitly set on request(), the timeout reset behavior does not seem to activate.

This makes resetTimeoutOnProgress behave more narrowly than its name suggests. It appears to be coupled to explicit callback registration rather than to the presence of valid progress activity for the request.

From my point of view, there are two reasonable outcomes.

One option would be to make resetTimeoutOnProgress work whenever the request is progress-capable and valid progress notifications are received, even if onprogress is not explicitly passed.

The other option would be to document clearly that resetTimeoutOnProgress only has an effect when onprogress is explicitly provided on the same request() call.

Start by tracing the low-level request() handling for resetTimeoutOnProgress and its relationship to onprogress. Reproduce a progress-capable request without an explicit callback, then compare the behavior with the callback case; done means either the timeout behavior matches the intended progress semantics or the limitation is documented clearly.