Distinguish request timeouts from intentional aborts in htmx:error

## Problem

With the installed htmx.org 4.0.0 distribution, a request timeout and an hx-sync replacement both produce an AbortError in htmx:error, and ctx.request.signal.reason.name is AbortError in both cases. Applications cannot use that reason to show connection-failure feedback for timeouts while keeping intentional cancellation silent.

## Reproduction

Serve an endpoint /slow that holds its response open, load htmx, and use:

```html
Send

document.addEventListener("htmx:error", ({detail: {ctx, error}}) => {
console.log(error.name, ctx.request.signal.reason?.name);
});

```

1. Click once and wait for the timeout: AbortError / AbortError.
2. Set hx-config="timeout:0", then click twice while the first request is pending: AbortError / AbortError for the replaced request.

I reproduced both cases in Chromium using the installed distribution without an application error handler.

## Expected behavior

Give timeout cancellation a distinguishable reason, such as new DOMException("Request timed out", "TimeoutError"), or expose a supported timeout discriminator on the error event. Intentional aborts should remain distinguishable.

The current #initTimeout implementation calls ctx.request.abort() without a reason. An application workaround can replace ctx.requestTimeout in htmx:before:request with a timer that supplies TimeoutError, but that depends on private timer initialization and cleanup rather than a supported error boundary.

Start at the #initTimeout implementation and trace how ctx.request.abort() reaches htmx:error, then compare it with hx-sync replacement cancellation. Reproduce the /slow example in Chromium and verify that timeout errors expose a distinct timeout reason while intentional aborts remain distinguishable.

Written by the indexing model from the issue text.