fix(Storage): ensure StorageClient retryStrategy is applied correctly to all operations

[salilg-eng]

Fixes #9334

The Problem:
When creating a StorageClient with a custom retryStrategy (like StorageClient::RETRY_ALWAYS), the strategy was being ignored for non-idempotent operations like deleting an object.

This happened because in Rest::send and Rest::headObject, the retry function (getRestRetryFunction) was being constructed before the client's retryStrategy was added to the request options. Due to this order of execution, it fell back to the default StorageClient::RETRY_IDEMPOTENT.

The Solution:

Moved the $options['retryStrategy'] ??= $this->retryStrategy; assignment up so it happens before getRestRetryFunction is called.
Added a new unit test (testAlwaysRetryStrategyWithNonIdempotentOpSuccessful) to verify that a non-idempotent operation (like delete) correctly respects RETRY_ALWAYS.
(Note: The previous test for this feature used createBucket, which is idempotent and always retries by default, which is why this bug slipped through initially).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Hectorhammett]

Hello @salilg-eng!

It seems like there are two different accounts in the commit history and it is detecting it as a non googler contribution, asking you to sign the CLA.

Why is there a "actions-user" account in two of the commits?

If we want to fix it, to my understanding we need to have only an approved account to be able to merge this :).