Pull request viewer does not load images from private repositories

[artieeg]

Problem

Images embedded in pull request descriptions from private repositories render as broken images in the pull request viewer. GitHub returns private user-attachments URLs as 404 when the desktop renderer fetches them anonymously, even though the signed-in GitHub CLI can access them.

Reproduction

1. Open a pull request from a private GitHub repository that contains uploaded images.
2. Open its Summary tab in the pull request viewer.
3. Scroll to the images in the description.

The image alt text and broken-image icon appear instead of the uploaded images.

Before

The screenshot uses public PR #6594 as seeded content with an unreferenced private test attachment substituted at render time. It contains no private pull request content.

[sensei-woo]

Additional reproduction: this also affects images committed to a private repository and embedded in ordinary pull request comments, not only github.com/user-attachments images in the PR description.

Example Markdown shape:

![screenshot.png](https://github.com/OWNER/PRIVATE-REPO/blob/<commit>/screenshot.png?raw=true)

In the Summary view, the Markdown table and image alt text render, but the image itself is broken. The PR/comment data is loaded through authenticated gh, while the renderer treats the HTTPS image as directly loadable and emits an ordinary <img src>; that browser request has no GitHub authentication.

The open fix in #6601 currently recognizes only https://github.com/user-attachments/assets/, so private repository blob/<sha>/<path>?raw=true images still take the anonymous path. This reproduction applies to PR comments and images inside Markdown tables as well as descriptions.

[PetrBrabec]

One finding that changes the fix shape for images committed to a private repo (the case in the comment above): the approach in #9404 / #10775 — attach the gh token to the github.com URL and follow its redirect — can't just be widened to cover them, because github.com's repo-file routes 404 even with the token.

Tested with curl against a private repo, a PNG committed to a branch, using the OAuth token from gh auth login (gh auth token):

URL form	anonymous	Authorization: token <gh token>
https://github.com/O/R/raw/<ref>/<path>	404	404
https://github.com/O/R/blob/<ref>/<path>?raw=true	404	404
https://raw.githubusercontent.com/O/R/<ref>/<path>	404	200 image/png
GET https://api.github.com/repos/O/R/contents/<path>?ref=<ref> → download_url	—	200 JSON; the download_url (signed ?token=) then loads anonymously, 200 image/png

So for repo images:

• The URL has to be rewritten to raw.githubusercontent.com/O/R/<ref>/<path> before the token goes on. That is a straight host/path rewrite that keeps the <ref>/<path> split untouched, so branch names containing / resolve exactly as they do on github.com.
• The 302-to-a-short-lived-URL design both PRs use still works: the contents API's download_url is a signed URL the renderer can load without credentials. That route takes ref and path separately, though, so it is the one that would have to split them apart itself.
• Rendering GitHub's body_html instead of the markdown doesn't help: it leaves these srcs untouched (<img src="https://github.com/O/R/raw/<ref>/<path>">). They only render on github.com because the viewer's session cookie goes along with the request.

Our shape, for reference: <img src="https://github.com/O/R/raw/develop/docs/…/screenshot.png" width="420" /> in a PR description. That's how we embed screenshots we commit to the repo so they stay private.

[juliusmarminge]

Fixed by #11706 — private repository media (images/videos) now loads in pull request tabs on web and desktop.