`azure-ai-agentserver-responses` `storage_error` masks the real underlying error (content_filter, timeout, etc.) in Foundry-hosted agent responses

- **Package Name**: `azure-ai-projects` / `agent-framework-foundry-hosting` / `azure-ai-agentserver-responses`
- **Package Version**: 2.1.0 / 1.0.0a260507 / 1.0.0b5
- **Python Version**: 3.13.13

---

**Describe the bug**

When sending requests to a Foundry-hosted agent and retrieving the agent response via polling, the polling process intermittently fails with a misleading `storage_error`.

The error message returned is:

```
Error code: storage_error
Error message: An internal error occurred while storing the response. Subsequent retrieval is not guaranteed. Please retry the request.
```

After further investigation, this error appears **not** to be an actual storage issue on the backend. Instead, it seems to originate from a **content filter** triggered on the OpenAI side, but the error is **not being propagated to the user correctly**.

**Expected OpenAI behavior:**
When the OpenAI content filter is triggered, the response object should normally contain:
- `"status"`: `"incomplete"`
- `"incomplete_details"`: `{ "reason": "content_filter" }`

**Observed behavior in Foundry-hosted agents:**
- `"status"` is returned as `"failed"` instead of `"incomplete"`.
- `"error_code"` is returned as `"storage_error"`, which is **not** a valid value in OpenAI's defined `ResponseError` codes.
- The actual root cause (`content_filter`) is completely hidden from the user, making it impossible to handle the situation properly (e.g., by adjusting the prompt or informing the end user that the content was filtered).

Because of this incorrect mapping, what is actually a deterministic content-filter rejection appears to the user as a random/intermittent storage failure, since the same input may pass or trigger the content filter depending on the model's non-deterministic output.

I also suspect that this same generic `storage_error` may be masking **other underlying error types as well** (e.g., timeouts, upstream model errors, or other transient failures). Since all of these seem to be collapsed into a single `storage_error` code, it is currently impossible to distinguish between fundamentally different failure modes from the client side.

**Screenshot**

**To Reproduce**

1. Send a request to a Foundry-hosted agent using `azure-ai-projects` (OpenAI client / responses API).
2. Use a prompt whose response is likely to trigger the OpenAI content filter.
3. Retrieve the agent response via the polling mechanism. (polling may be optional)
4. Observe that the request fails with:
- `"status": "failed"`
- `"error_code": "storage_error"`

instead of the expected:
- `"status": "incomplete"`
- `"incomplete_details": { "reason": "content_filter" }`

**Expected behavior**

- When the OpenAI content filter is triggered, the response should be returned with `"status": "incomplete"` and `"incomplete_details.reason": "content_filter"`, in line with the OpenAI Responses API contract.
- The `error_code` field should only contain values defined by OpenAI's `ResponseError` schema; custom/undefined values such as `storage_error` should not be used to mask content-filter rejections.
- Other underlying failures (timeouts, upstream errors, etc.) should likewise be surfaced with their own distinct, accurate error codes rather than being collapsed into a generic `storage_error`.
- The user should be able to distinguish a genuine backend storage failure from a content-policy rejection, so that the issue can be handled appropriately on the client side.