Missing error check for failed HTTP responses in OCI middleware manifest fetch

### Checklist - [x] I added a descriptive title - [x] I searched open reports and couldn't find a duplicate ### What happened? ## Summary When fetching an OCI manifest in `rattler_networking`, the HTTP response is not checked for a successful status code before attempting to deserialize its body as JSON. This leads to cryptic, confusing error messages when the request fails (e.g., 404 Not Found, 401 Unauthorized, 500 Internal Server Error). -256 (inside `OCIUrl::get_blob_url`) ## Current Behavior ```rust let manifest = client .client() .get(manifest_url) .bearer_auth(&token) .header(ACCEPT, "application/vnd.oci.image.manifest.v1+json") .send() .await?; let manifest: Manifest = manifest.json().await?; // <- no status check here ``` If the server responds with a non-2xx status code (e.g., a 404 for a non-existent repository or 403 for a private one), the code attempts to parse the error response body as a Manifest JSON object. This results in a serde_json deserialization error that is completely opaque to the user, hiding the actual underlying cause (e.g., "Not Found", "Forbidden"). ### Contrast With Token Fetch Notably, the get_token function in the same file correctly handles HTTP status errors: ```rust match response.error_for_status() { Ok(response) => { ... } Err(e) => { tracing::error!("OCI Mirror: failed to get token with URL: {}", token_url); Err(OciMiddlewareError::Reqwest(e)) } } ``` The manifest fetch does not follow this same pattern. ## Proposed Fix Call .error_for_status() on the manifest response before trying to deserialize it, following the same pattern as get_token: ```rust let manifest_response = client .client() .get(manifest_url) .bearer_auth(&token) .header(ACCEPT, "application/vnd.oci.image.manifest.v1+json") .send() .await? .error_for_status() .map_err(OciMiddlewareError::Reqwest)?; // or a more specific error variant let manifest: Manifest = manifest_response.json().await?; ``` This ensures that failed requests surface meaningful HTTP error messages rather than confusing JSON parse failures. ## Impact - Incorrect UX: Users see error deserializing JSON when the real cause is 404 Not Found or 403 Forbidden. - - Debugging difficulty: The error message gives no indication that the problem is a network-level failure. ## Difficulty This is a beginner-friendly fix. It requires: - Understanding the existing get_token pattern in the same file. - - Calling .error_for_status() on the response. - - - Writing a test or updating an existing integration test to verify the behavior on a simulated 4xx response. - - - ## Location **File:** `crates/rattler_networking/src/oci_middleware.rs` **Lines:** ~248 ### Additional Context _No response_