Use canonical management URL construction for HTTP payloads #233

Summary

Complete HTTP management payload URL parity instead of reconstructing only a subset of the host's management links.

The binding already provides host-generated management URL metadata, but the current clients ignore managementUrls and build URLs locally from a hard-coded route shape.

Current behavior

• HttpManagementPayload omits the host-supported rewindPostUri.
• Async and sync clients construct /runtime/webhooks/durabletask/instances/... directly instead of using the canonical host-provided URL shape.
• URL construction ignores Forwarded, X-Forwarded-Proto, and X-Forwarded-Host, so responses can expose an internal scheme or authority behind a reverse proxy or ingress.
• Locally reconstructing routes can drift from host changes and configured webhook paths.

Expected behavior

Centralize management URL construction and preserve all canonical payload fields:

• statusQueryGetUri
• sendEventPostUri
• terminatePostUri
• rewindPostUri
• purgeHistoryDeleteUri
• restartPostUri
• suspendPostUri
• resumePostUri

Prefer the host-provided management URL metadata where possible, while still replacing the instance placeholder and using the externally visible request origin according to the Durable Functions proxy-header conventions.

Acceptance criteria

• rewindPostUri is present in mapping access, .urls, to_json(), and serialized check-status responses.
• Async and sync clients generate identical payloads.
• Instance IDs and query parameters remain correctly encoded.
• Request-origin behavior is covered for direct requests, Forwarded, and X-Forwarded-* headers.
• Existing required query parameters and management URL templates remain intact.
• Tests verify all canonical management URL fields.