[BUG] Azure Maps geocoder returns inconsistent results in when trying to geocode using Threadpool

### API Spec link

https://atlas.microsoft.com/geocode

### API Spec version

2023-06-01

### Describe the bug

Azure Maps Geocoding API returns non-deterministic results for the same address when submitted as part of a batch geocoding workflow.

The issue was observed while processing a dataset containing more than 50 addresses using a batch size of 50. One specific address consistently exhibits inconsistent geocoding behavior across repeated executions of the same request.

Input address:

```json
{
"addressLine": "175 Liberty Street",
"locality": "Niles",
"adminDistrict": "Michigan",
"postalCode": "49120",
"countryRegion": "United States"
}
```

The same input occasionally resolves to different geographic locations, including different cities, states, and ZIP codes.

The issue is partially reproducible (doesn't occur 100% of the times) and occurs even when:

- Request payloads are identical
- Batch ordering is unchanged
- Dataset contents are unchanged
- Requests are executed several seconds apart

### Expected behavior

# Expected Behavior

The geocoding service should return deterministic results for identical requests.

Given the following input:

```json
{
"addressLine": "175 Liberty Street",
"locality": "Niles",
"adminDistrict": "Michigan",
"postalCode": "49120",
"countryRegion": "United States"
}
```

Expected behavior:

- The same address should consistently resolve to the same geocoding result.
- Candidate ranking should remain stable across executions.
- Locality, state, and postal code constraints supplied in the request should be respected.
- The service should not intermittently return addresses from a different state or ZIP code.
- If multiple candidates exist, ambiguity should be explicitly surfaced rather than changing the top-ranked result between requests.

### Actual behavior

# Actual Behavior

The same address returns different results across repeated executions.

Observed results:

| Run | Returned Address |
|------|------------------|
| 1 | 175 Liberty St, Niles, OH 44446, United States |
| 2 | 175 Liberty St, Buchanan, MI 49107, United States |
| 3 | 175 Liberty St, Buchanan, MI 49107, United States |
| 4 | 175 Liberty St, Buchanan, MI 49107, United States |
| 5 | 175 Liberty St, Buchanan, MI 49107, United States |

The first execution returned an address in:

```text
Niles, OH 44446
```

while subsequent executions returned:

```text
Buchanan, MI 49107
```

This occurs despite using the exact same input payload and batch contents.

No exceptions, throttling errors, or HTTP failures were observed.

Impact:

- Inconsistent address normalization
- Duplicate record generation
- Unstable matching behavior
- Cache invalidation issues
- Data quality concerns in downstream systems

### Reproduction Steps

# Reproduction Steps

## Test Configuration

- Dataset size: > 50 addresses
- Batch size: 50
- Azure Maps Geocoding API Version: 2023-06-01
- Test address included in batch
- Test address observed at batch index 48

## Input Address

```json
{
"addressLine": "175 Liberty Street",
"locality": "Niles",
"adminDistrict": "Michigan",
"postalCode": "49120",
"countryRegion": "United States"
}
```

## Steps

1. Create a dataset containing more than 50 valid addresses.
2. Include the test address shown above.
3. Submit the dataset using Azure Maps batch geocoding.
4. Process requests using a batch size of 50.
5. Observe the result corresponding to the test address.
6. Repeat the exact same request multiple times.
7. Compare the returned geocoding results.

## Sample Code

```python
import time

for run in range(5):
try:
geocode_responses, successful_payloads, failed_responses = run_req()

# Index 48 corresponds to the test address
result = (
geocode_responses[48]["value"]
.json()["features"][0]["properties"]["address"]["formattedAddress"]
)

print(f"Run {run + 1}: {result}")

time.sleep(5)

except Exception as exc:
print(f"Error during geocoding: {exc}")
```

## Simplified Pseudocode

```text
dataset = create_dataset(size > 50)

insert test address:
175 Liberty Street
Niles, MI 49120

repeat 5 times:

submit identical batch request

retrieve result for test address

store formatted address

wait 5 seconds

compare results across runs
```

### Environment

# Environment

| Property | Value |
|-----------|--------|
| Service | Azure Maps Geocoding API |
| API Version | 2023-06-01 |
| Request Type | Batch Geocoding |
| Batch Size | 50 |
| Dataset Size | > 50 Addresses |
| Programming Language | Python |
| Execution Environment | Jupyter Notebook |
| Operating System | Linux / macOS |

## SDK / Libraries

```text
Python: 3.13.5
requests: 2.32.4
azure-maps api version: 2023-06-01
```

## Additional Notes

- The issue is partially reproducible (the inconsistent result comes very randomly).
- The issue affects some specific addresses consistently (similar behaviour observed for other addresses as well such as `950 Oak St, Frankfort, Franklin County, Kentucky, 40601, United States`).
- This issue has only been observed when sending requests in batches of 50
- No API errors or throttling responses were observed.
- The problem appears related to candidate selection or ranking for the affected address.

Start with the Azure Maps geocode API specification linked in the issue and run the provided Python batch reproduction using the 50-address dataset and test address. Compare the result at index 48 across five identical requests; done means determining whether the inconsistent candidate selection is reproducible and identifying the relevant API behavior or specification gap.

Written by the indexing model from the issue text.