[BUG] `FluidRelay`: `FluidRelayServers_Delete` spec response code (204) does not match with API (202)

### API Spec link

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/fluidrelay/resource-manager/Microsoft.FluidRelay/stable

### API Spec version

All

### Describe the bug

In `FluidRelay` spec, the expected response code for the `FluidRelayServers_Delete` operation (204 NoContent) does not match the actual response code returned from the DELETE operation of the API (202 Accepted).

I believe that the spec is incorrect, as the DELETE operation from the API returns the `202 Accepted` along with the `azure-asyncoperation` response header and can be polled until completion, typical with other LRO behavior.

Example from latest stable version, but present in all versions: https://github.com/Azure/azure-rest-api-specs/blob/main/specification/fluidrelay/resource-manager/Microsoft.FluidRelay/stable/2022-06-01/fluidrelay.json#L246

### Expected behavior

```
DELETE https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.FluidRelay/fluidRelayServers/?api-version=2022-05-26
```

Returns response code `202 Accepted`, which spec should treat as "success".

### Actual behavior

```
DELETE https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.FluidRelay/fluidRelayServers/?api-version=2022-05-26
```

Returns response code `202 Accepted`, which spec treats as "failed" with error.

### Reproduction Steps

When building an SDK based on the existing spec, the result for the DELETE operation will be something similar to the following, with no expected polling steps:
```
ExpectedStatusCodes: []int{
http.StatusNoContent,
http.StatusOK,
},
```

This will always raise an error in the SDK due to actual API call always returning `http.StatusAccepted`.

### Environment

_No response_

Open specification/fluidrelay/resource-manager/Microsoft.FluidRelay/stable/2022-06-01/fluidrelay.json around line 246 and inspect the FluidRelayServers_Delete operation. Compare its documented response with the reported 202 Accepted response and azure-asyncoperation header. Done means the spec represents the successful asynchronous delete behavior so generated SDKs accept and poll it correctly.

Written by the indexing model from the issue text.