fix: don't report coroutine cancellations as resolve errors in telemetry

[fabriziodemaria]

Summary

• CancellationException in RemoteFlagResolver.resolve() was caught by the generic catch (e: Exception) branch and tracked as STATUS_ERROR in telemetry. This inflated the confidence_sdk_telemetry_resolve_latency_seconds_count{status="STATUS_ERROR"} metric significantly — every putContext(), fetchAndActivate(), or asyncFetch() call cancels any in-flight resolve before starting a new one, and each cancellation was misreported as an error.
• With a simulated cancel-and-replace pattern (3 rapid context changes per cycle), the SDK would report ~47% STATUS_ERROR with zero actual network failures. This matches the consistently high error ratios observed in production across all PLATFORM_KOTLIN customers.
• The fix catches CancellationException before the generic Exception handler and skips telemetry tracking entirely for cancelled requests.
• Also fixes a pre-existing nullability mismatch in TelemetryTest.kt (encodedHeaderValue() returns String? but decodeMonitoring() expected non-null String).

Test plan

• testCancelledResolveDoesNotTrackTelemetry — verifies cancelled resolve produces no telemetry trace
• testSuccessfulResolveTracksTelemetry — verifies successful resolve still produces a telemetry trace
• testFailedResolveTracksTelemetryAsError — verifies HTTP errors still produce a telemetry trace
• All existing ConfidenceRemoteClientTests and TelemetryTest pass

Made with Cursor