[BUG] RequestRetryOptions tryTimeout has no effect on synchronous Storage clients

Describe the bug
For synchronous Storage clients (for example BlobServiceClient), the per-try timeout configured with RequestRetryOptions (tryTimeout) never fires. A stalled request runs until the HTTP client's own timeout (60 s by default for Netty) instead of the configured try timeout. The async client with the same options times out as expected.

Root cause
RequestRetryPolicy.attemptSync runs each try as:

Mono<HttpResponse> httpResponseMono = Mono.fromCallable(() -> next.clone().processSync());
httpResponseMono = httpResponseMono.timeout(this.requestRetryOptions.getTryTimeoutDuration());
HttpResponse response = httpResponseMono.block();

Mono.fromCallable runs the blocking processSync() on the subscribing thread inside request(n). In FluxTimeout.TimeoutMainSubscriber.onSubscribe, actual.onSubscribe(this) (which triggers request(n) and therefore the whole blocking call) runs before firstTimeout.subscribe(timeoutSubscriber) arms the timer. By the time the timer is armed, the value has already been emitted, so the timeout can never fire. attemptAsync is not affected because process() does not block on subscribe.

Stack of a sync call blocked on a stalled server (trimmed):

reactor.core.publisher.Mono.block(Mono.java:1779)
com.azure.core.http.netty.NettyAsyncHttpClient.sendSync(NettyAsyncHttpClient.java:194)
...
com.azure.storage.common.policy.RequestRetryPolicy.lambda$attemptSync$0(RequestRetryPolicy.java:266)
reactor.core.publisher.MonoCallable$MonoCallableSubscription.request(MonoCallable.java:137)
reactor.core.publisher.Operators$MultiSubscriptionSubscriber.request(Operators.java:2330)
reactor.core.publisher.SerializedSubscriber.request(SerializedSubscriber.java:151)

To Reproduce
Point a client at a server that accepts the TCP connection but never responds (a ServerSocket that is never accept()ed is enough), with maxTries = 1 and tryTimeout = 1s.

Code Snippet

import com.azure.storage.blob.BlobServiceClientBuilder;
import com.azure.storage.common.StorageSharedKeyCredential;
import com.azure.storage.common.policy.RequestRetryOptions;
import com.azure.storage.common.policy.RetryPolicyType;
import java.net.ServerSocket;
import java.time.OffsetDateTime;

public class TryTimeoutRepro {
  public static void main(String[] args) throws Exception {
    // The listen backlog completes the TCP handshake, but nothing is ever written back.
    try (ServerSocket stalled = new ServerSocket(0)) {
      BlobServiceClientBuilder builder = new BlobServiceClientBuilder()
          .endpoint("http://127.0.0.1:" + stalled.getLocalPort() + "/devstoreaccount1")
          .credential(new StorageSharedKeyCredential("devstoreaccount1",
              "Eby8vdM02xNOcqCfGfP/mkP3+rZTt5tF5If1fMvj08QzZLOiT4E5lZaz0smU4wFwbIsrpPoIQx=="))
          .retryOptions(new RequestRetryOptions(RetryPolicyType.EXPONENTIAL,
              1 /* maxTries */, 1 /* tryTimeoutInSeconds */, null, null, null));
      OffsetDateTime start = OffsetDateTime.now();

      long t0 = System.nanoTime();
      try {
        builder.buildAsyncClient().getUserDelegationKey(start, start.plusHours(1)).block();
      } catch (RuntimeException e) {
        System.out.println("async: " + e.getCause() + " after " + ms(t0) + " ms");
      }

      t0 = System.nanoTime();
      try {
        builder.buildClient().getUserDelegationKey(start, start.plusHours(1));
      } catch (RuntimeException e) {
        System.out.println("sync: " + e + " after " + ms(t0) + " ms");
      }
    }
  }

  private static long ms(long t0) {
    return (System.nanoTime() - t0) / 1_000_000;
  }
}

Observed with an equivalent test:

• async: TimeoutException after ~1009 ms
• sync: still running after 5000 ms; each try only ends at the HTTP client's 60 s response timeout (two tries took ~120 s)

The same behavior in plain Reactor:

Mono.fromCallable(() -> { Thread.sleep(4000); return "OK"; })
    .timeout(Duration.ofSeconds(1))
    .block();                                   // returns "OK" after ~4001 ms, no timeout

Mono.fromCallable(() -> { Thread.sleep(4000); return "OK"; })
    .subscribeOn(Schedulers.boundedElastic())
    .timeout(Duration.ofSeconds(1))
    .block();                                   // TimeoutException after ~1003 ms

Expected behavior
Each sync try fails with a timeout after tryTimeout and is retried, the same as on the async client.

Possible fix
Run the blocking call off the subscribing thread (for example subscribeOn(Schedulers.boundedElastic())), or enforce the timeout with an executor and Future.get(timeout). If changing this is not desirable, documenting that tryTimeout does not apply to sync clients would help.

Workaround
Set connect, response and read timeouts on the HTTP client (NettyAsyncHttpClientBuilder) and pass it with .httpClient(...), or use the async client.

Setup

• OS: Ubuntu 20.04 (x86_64)
• Library/Libraries: azure-storage-blob 12.36.0, azure-storage-common 12.35.0, azure-core 1.60.0, azure-core-http-netty 1.16.8, reactor-core 3.7.19, reactor-netty-http 1.2.18. The code in RequestRetryPolicy.attemptSync is unchanged on main.
• Java version: 25 (GraalVM 25.0.4)
• Frameworks: none

Information Checklist

• Bug Description Added
• Repro Steps Added
• Setup information Added