tracking: Azure Blob Delete does not honor If-None-Match wildcard semantics

### Summary

Azure Blob Storage's `Delete Blob` API accepts `If-None-Match`, but the live service does not apply the documented wildcard semantics when the value is `*`. It deletes an existing blob instead of rejecting the request.

This is an Azure Blob Storage service behavior discrepancy, not an OpenDAL bug. OpenDAL forwards the standard `If-None-Match` header unchanged.

### Live service reproduction

Reproduced against the actual Azure Blob Storage service on 2026-08-27 using raw Shared Key REST requests, without OpenDAL or Azurite. The requests used `x-ms-version: 2022-11-02`.

Wildcard case:

1. Create a blob: `201 Created`.
2. Delete it with `If-None-Match: *`: `202 Accepted`.
3. Issue `HEAD` for the blob: `404 BlobNotFound`.

The wildcard DELETE request ID was `91443d9d-701e-0018-5cfc-354f9c000000`.

Control case using the blob's current ETag:

1. Create another blob: `201 Created`.
2. Delete it with `If-None-Match: `: `412 ConditionNotMet`.
3. Issue `HEAD` for the blob: `200 OK`.

The control DELETE request ID was `c1929a10-701e-006a-13fc-3548d3000000`.

The control confirms that Azure evaluates `If-None-Match` for `DELETE`, but does not recognize `*` with its documented wildcard meaning.

### Expected behavior

Azure documents that `If-None-Match` accepts `*`, and that the wildcard condition fails when the target resource exists. For a `DELETE` request, the service should return `412 Precondition Failed` and leave the blob intact.

This also follows the HTTP semantics in RFC 9110 Section 13.1.2.

- [Azure Blob Storage conditional headers](https://learn.microsoft.com/en-us/rest/api/storageservices/specifying-conditional-headers-for-blob-service-operations)
- [Delete Blob](https://learn.microsoft.com/en-us/rest/api/storageservices/delete-blob)
- [RFC 9110 Section 13.1.2](https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.2)

### OpenDAL impact

This issue tracks the external service limitation and any future Azure resolution. It does not propose an OpenDAL fix:

- OpenDAL already sends the caller-provided `If-None-Match` value as a standard HTTP header.
- Emulating the condition with `HEAD` followed by unconditional `DELETE` would introduce a race and would not provide atomic conditional-delete semantics.
- OpenDAL may document or test this provider limitation where relevant, but it should not claim that Azure honors wildcard conditional delete until the live service behavior changes.

Related to #8141 and #8157.

AI assisted with the live-service reproduction and drafting. The contributor directed the scope and conclusion.

Review related issues #8141 and #8157 alongside the linked Azure Blob Storage and RFC 9110 documentation. The issue identifies no OpenDAL file or test to change; done would require documenting or testing the provider limitation only if maintainers define that scope, or tracking an Azure service correction.

Written by the indexing model from the issue text.