Record HTTP status code on blob-hydration failure telemetry

[tyrielv]

Problem

When an on-demand loose-blob download fails, GVFS emits a terminal telemetry error TryCopyBlobContentStream: Failed to provide blob contents tagged with a BlobHydrationFailureCategory. The DownloadFailed category is the transient/unclassified bucket, so it collapses both genuine auth failures (HTTP 401/400/302) and transient failures (timeout 408, 5xx, connection-pool-exhaustion 503) into one value.

The HTTP status of the failing download is already known inside the code, but it is only written to the on-box GVFS log (an Informational event that is not shipped). It never reaches shipped telemetry. As a result, you cannot tell from telemetry whether blob failures were real 401s or transient failures.

Change

Carry the HTTP status of the last download attempt through to the point where the terminal failure telemetry is emitted, and add it to that event's metadata:

• A new internal DownloadAttemptResult type carries both the existing DownloadAndSaveObjectResult outcome and the HttpStatusCode? of the last attempt.
• DoDownloadAndSaveObject and the private coalescing TryDownloadAndSaveObject now return the richer type; the inflightDownloads coalescing dictionary holds Lazy<DownloadAttemptResult>.
• The public DownloadAndSaveObjectResult TryDownloadAndSaveObject(...) overload is unchanged, so callers in InProcessMount and GVFSVerb are unaffected.
• The terminal-failure OnFailure handler adds HttpStatusCode (int) and HttpStatusName (string) to the event metadata only when the failure is attributable to the download itself (category DownloadFailed or ObjectNotOnServer). On the exception (LocalIO/NetworkUnavailable) and LocalCopyFailed paths the status is suppressed, so an earlier attempt's status cannot attach to a later, differently-caused terminal event. When no HTTP response was received (exhausted-retry exception, or a failure carrying no status), no status keys are emitted. Existing BlobHydrationFailureCategory bucketing is preserved and the new keys are purely additive.

No credential/auth logic, HttpRequestor, or RetryWrapper behavior changes.

Tests

GVFSGitObjectsTests (23/23 pass):

• 401 (auth): a download failing with Unauthorized produces a terminal event containing "HttpStatusCode":401 / "HttpStatusName":"Unauthorized", still bucketed DownloadFailed.
• 503 (transient): a download failing with ServiceUnavailable produces "HttpStatusCode":503 / "HttpStatusName":"ServiceUnavailable" — directly exercising the auth-vs-transient split.
• No status: a download that fails without an HTTP response emits no HttpStatusCode/HttpStatusName keys (guards against ever emitting "HttpStatusCode":0).