HTTP API: Use the actual HTTP status code in download_url() error codes

[hinnerk-a]

Trac ticket: https://core.trac.wordpress.org/ticket/60564

download_url() returns a WP_Error with the code http_404 for every non-200 response. A 403, 406 or 500 is indistinguishable from a real 404 unless the caller digs the status code out of get_error_data().

This PR names the error after the actual status code (http_403, http_500, ...), the same convention Site Health already uses for its own HTTP errors ('http_' . wp_remote_retrieve_response_code() in class-wp-site-health.php). It builds on #8187 by @Vedant-Gandhi and adds:

• a fallback to the historical http_404 when the response carries no status code at all (wp_remote_retrieve_response_code() returns '' for a pre_http_request short-circuit without a response array — the one-liner would have produced http_);
• a @since note in the docblock;
• unit tests: the existing 418 test now also asserts the error code, plus a data provider over 403/404/406/500/503 and a test for the no-status-code fallback. All fail on trunk except the two http_404 cases.

Backward compatibility: only callers comparing get_error_code() against the literal 'http_404' are affected, and for those the old code was wrong for every status but 404. Nothing in core does this; the error message and get_error_data() (code, body) are unchanged. Probably worth a line in the 7.2 misc dev note.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props hinnerk.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.