Conditional updates with optimistic locking is not working

Nobody has claimed this yet.

**Describe the bug**
When performing a conditional update, using the `If-Match` with the etag, it seems to be ignoring the `if-match` header as the update is being performed regardless of incorrect version (etag).

**FHIR Version?**
R4

**Data provider?**
The default on an Azure Health Data FHIR Service install (the managed FHIR Service within Azure).

**To Reproduce**
Steps to reproduce the behavior:
1. Ensure there exists a resource that would match a search criteria.
-- For example, an ImagingStudy resource with an identifier of
```
"identifier": [
{
"type": {
"coding": [
{
"system": "http//terminology.hl7.org/NamingSystem/dui",
"code": "DUI"
}
]
},
"system": "urn:dicom:uid",
"value": "urn:oid:the-dicom-study-id"
}
]
```
3. Read the ImagingStudy using the search with the above criteria.
-- For example: GET [baseFhirUrl]/ImagingStudy?identifier=urn%3Adicom%3Auid%7Curn%3Aoid%3A**the-dicom-study-id**
-- Make note of the Meta.Version value. Let's say the current version is **5**.
5. Create the body (same as the GET response from the previous step), change a field to ensure version would be incremented on an update (say, change the `status` value). Update this resource using a PUT request with a search condition. Ensure there is an `If-Match` header with the previous version ETag. In this case, `If-Match: W/"4"`.
-- For example: PUT [baseFhirUrl]/ImagingStudy?identifier=urn%3Adicom%3Auid%7Curn%3Aoid%3A**the-dicom-study-id**
-- Header: `If-Match: W/"4"`.

**Expected behavior**
The request should be rejected with `412 - Precondition failed`.

**Actual behavior**
The request is accepted (with 200 - OK), the resource is updated and version is incremented to 6.

According to [REST API capabilities in the FHIR service in Azure Health Data Services](https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/rest-api-capabilities#conditional-createupdate) conditional updates with optimistic locking should be supported.

Mentioning that this sometimes works, seemingly randomly. The scenario we have does attempt to conditionally update (with optimistic locking) the same resource within a very short time frame (nano seconds). However, it is very easy to reproduce in a non-concurrent scenario as well, so above repro steps should work.

Perhaps related with [Concurrent conditional creates results in duplicate data](https://github.com/microsoft/fhir-server/issues/1382).

Start by reproducing the conditional PUT against the ImagingStudy search endpoint with an intentionally incorrect If-Match ETag, then trace the conditional update and optimistic-locking request path. Done means the request is rejected with HTTP 412 and the resource is not updated or version-incremented.

Written by the indexing model from the issue text.