Honor forwarded headers when creating management URLs

🐛 **Describe the bug**
> A clear and concise description of what the bug is.

`DurableOrchestrationClient.create_check_status_response()` and `get_client_response_links()` do not consider `Forwarded`, `X-Forwarded-Host`, or `X-Forwarded-Proto` when constructing management URLs.

The SDK copies the extension-provided management URL templates, then unconditionally replaces their origin with the scheme and authority from `request.url`. Behind Azure Front Door, Application Gateway, or another reverse proxy, `request.url` can contain the internal origin. The resulting `Location`, `statusQueryGetUri`, and other management URLs can therefore expose an internal hostname or use HTTP even when forwarded headers describe the public HTTPS origin.

The Durable Functions extension added opt-in forwarded-header support in Azure/azure-functions-durable-extension#3083. Out-of-process binding templates are generated without an HTTP request, however, and the Python SDK subsequently replaces their origin from `request.url`, so that extension behavior does not cover this Python path.

This is separate from #355: current Azure Linux managed hosting correctly returns HTTPS management URLs for ordinary HTTPS-only Function Apps.

🤔 **Expected behavior**
> What should have happened?

When trusted forwarded-header handling is enabled, Python-generated management URLs should use the client-facing scheme and host from `Forwarded` or `X-Forwarded-Proto`/`X-Forwarded-Host`, consistent with the Durable Functions extension behavior. Without opt-in, existing `request.url` behavior should remain unchanged.

☕ **Steps to reproduce**
> What Durable Functions patterns are you using, if any?
> Any minimal reproducer we can use?
> Are you running this locally or on Azure?

1. Run a Python Durable Functions HTTP starter behind a reverse proxy.
2. Have the proxy forward a public HTTPS origin using `X-Forwarded-Proto: https` and `X-Forwarded-Host: public.example.com`, while the worker receives an internal `request.url` such as `http://internal.example/api/start`.
3. Return `client.create_check_status_response(req, instance_id)`.
4. Observe that the management URL origins use `http://internal.example` rather than `https://public.example.com`.

A source-level reproduction is also sufficient: initialize the client with an HTTPS management URL template, call `get_client_response_links()` with an HTTP `request.url`, and observe that `_replace_url_origin()` downgrades the template to HTTP.

Relevant implementation: `azure/durable_functions/models/DurableOrchestrationClient.py`, in `get_client_response_links()` and `_replace_url_origin()`.

⚡**If deployed to Azure**
> We have access to a lot of telemetry that can help with investigations. Please provide as much of the following information as you can to help us investigate!

- **Timeframe issue observed**: N/A; identified through source analysis of reverse-proxy behavior
- **Function App name**: N/A
- **Function name(s)**: N/A
- **Azure region**: N/A
- **Orchestration instance ID(s)**: N/A
- **Azure storage account name**: N/A

> If you don't want to share your Function App or storage account name GitHub, please at least share the orchestration instance ID. Otherwise it's extremely difficult to look up information.

azure/durable_functions/models/DurableOrchestrationClient.py で get_client_response_links() と _replace_url_origin() を読むことから始めます。issue にあるソースレベルの再現を使って、request.url が管理 URL の origin をどのように置き換えるかを追跡し、その後、転送ヘッダーの想定される opt-in 動作を確認します。信頼された Forwarded または X-Forwarded ヘッダーによってクライアント向けの scheme と host が生成され、デフォルトの動作は変更されない状態になれば完了です。

索引モデルが issue の本文から書いたものです。