[Tmwakalasya]

Why?

The Phabricator provider reports rejected Conduit HTTP responses as plain error strings. The HTTP classifier cannot recover their status codes, so rate limits (429) and temporary outages (503) take the non-retryable path.

What?

Wrap the existing platform/http.StatusError at the Conduit response boundary, preserving the status and response body through the provider's error chain. The existing classifier can then distinguish retryable responses from permanent failures such as 400 and 401. Body-read failures retain their existing wrapped read error.

Add provider-level regression cases for 429, 503, 400, and 401, plus an assertion that body-read errors remain discoverable with errors.Is.

Test Plan

The four new status-error cases failed against the original implementation because *http.StatusError was absent from the returned error chain, then passed with the fix.

Passed locally:

./tool/bazel test //submitqueue/extension/changeprovider/phabricator:go_default_test //platform/http:go_default_test //platform/errs/http:go_default_test --test_output=errors
./tool/bazel run @rules_go//go -- vet -mod=readonly ./submitqueue/extension/changeprovider/phabricator
make fmt
make lint check-tidy check-gazelle

Full integration and end-to-end suites were not run; validation covers the provider and HTTP error-classification boundaries.

Issue

No linked issue.

[Tmwakalasya]

@behinddwalls I merged main after your approval, so the workflow needs approval again. Could you approve it? Auto-merge should take it from there. (The earlier failure on 7be48ac was a transient proxy.golang.org fetch error, unrelated to this change. My apologies