hardening(urllib): make redirect rejection explicit

[seonghobae]

Outcome

Make the two organization-owned urllib.request.HTTPRedirectHandler subclasses reject redirects explicitly by raising HTTPError from redirect_request.

RCA correction

The original Sentinel description classified the existing implementation as a HIGH SSRF vulnerability. Fresh review and the Python 3.14 urllib.request contract show that classification was incorrect: returning None from redirect_request means this handler cannot handle the redirect and allows another handler to try; with the current opener composition the redirect target was not followed. The existing code therefore already blocked redirects. This PR is defensive contract hardening, not remediation of an active SSRF bypass.

Python's documented contract says to raise HTTPError when no other handler should try to handle the redirected URL, while returning None is appropriate when another handler may handle it. These openers intentionally allow no redirect handling, so explicit HTTPError better states the invariant and fails closed without relying on fallback-handler composition.

Changes

• NoRedirectHandler.redirect_request() raises HTTPError directly;
• _NoPagesRedirects.redirect_request() does the same;
• existing direct handler regressions require the explicit exception;
• the false vulnerability entry and generated pr_description.txt artifact were removed after review corrected the causal classification.

Safety boundary

No URL allowlist, origin validation, request destination, credential, workflow permission, branch protection, scanner threshold, or merge authority changes. Fresh exact-head checks/reviews are required; predecessor evidence does not transfer.

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[seonghobae]

QUEUE_SATURATION_CHICKEN_EGG admission exception verified on exact head 993d8f16b54ca4b3cca8a861cacf8fec5d13075b: GitHub reports the PR mechanically mergeable with zero unresolved review threads; the only Devin finding is resolved/informational and the current-head Devin status is success. Exact-head hosted evidence already includes full Repository Metadata Reconcile success (run 33540870960, whose validation executes the complete pytest suite plus focused 100% metadata coverage/docstring gates), Security Scan success (33540871128), SAST Semgrep success (33540871189), Secret Scan success (33540871223), and Scorecard success (33540871216). The remaining OSV, SBOM, CodeQL and Python Security runs are still queued while the repository currently has 832 queued Actions runs. No substantive test/security/review failure, conflict, malformed provenance, or meaningful CHANGES_REQUESTED is being bypassed. Merge must use expected head identity; predecessor evidence will not be transferred to any later head.