[bmehta001]

Summary

Reduce avoidable duplicate uploads when cancellation races with an already completed Apple HTTP response. Related to #1542; this is a partial mitigation, not a resolution of the full issue.

• Preserve the existing HTTP 200 result, headers and body only when NSURLSession completed without error and response headers passed the existing size limit.
• Keep pending cancellation authoritative for transport errors (including cancellation and connection loss), missing HTTP responses, oversized headers and non-200 responses. The streaming delegate's response-body cap remains unchanged.
• Add deterministic tests against the actual response handler using a helper compiled only in Apple unit-test builds. No new shipping state, configuration, public API or client-side deduplication machinery.

Validation

• Changed C++ ranges pass the repository clang-format configuration; Objective-C++ ranges use the same configuration with its language set to ObjC because the checked-in configuration declares only Cpp. Whitespace checks pass.
• Windows / Visual Studio 2026: UnitTests build passed; all 38 tests selected by HttpClientTests.*:HttpResponseDecoderTests.* passed.
• WSL / Ubuntu / GCC 13: UnitTests build passed with the checked-out Azure Monitor module enabled; all 21 tests selected by the same filter passed. The initial local AZMON=OFF configuration could not link the module's auto-discovered tests; enabling the module resolved this without source changes or test exclusions.
• Apple CI: the macos-14 Release / iPhone 15 simulator job passed. Its actual logs confirm all three new tests ran and passed: CompletedAppleResponseSurvivesPendingCancellation, PendingAppleCancellationDoesNotAcceptUnconfirmedResponses, and AppleResponseValidationWithoutCancellationIsUnchanged. Unit and functional XCTest suites also passed in that job: https://github.com/microsoft/cpp_client_telemetry/actions/runs/41979913757/job/127087389622
• No negative test filters or new skipped tests. The new tests are intentionally Apple-transport-only and are not exercised by Windows/Linux runs. The remaining CI matrix is still running; physical-device lifecycle behavior was not tested.

Scope

This does not prevent duplicate ingestion after a lost acknowledgement or abrupt termination. Retrying ambiguous uploads remains intentional to avoid losing telemetry. Receiver-side idempotency/deduplication is still needed for that broader problem, which remains open.