[Bug]: Renamed Forgejo repos break PR links forever: requestFj won't follow the 301, so every sync sweep re-reads them #32617

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (Forgejo source control provider)

Steps to reproduce

1. On a self-hosted Forgejo, have an agent open some PRs in me/old-name and link them to threads (the normal agent link source).
2. Rename the repo to me/new-name in Forgejo.
3. Leave T3 Code running.

Expected behavior

The PR links keep syncing. Forgejo answers the old API path with a 301 to the new one, so following it on the same host should just work. Or at least a link that can't be read stops being re-read every minute.

Actual behavior

Every read of those links fails, forever:

PullRequestProviderError: forgejo failed in repos/me/old-name/pulls/29: Forgejo API request failed (HTTP 301): <a href="/api/v1/repos/me/new-name/pulls/29">Moved Permanently</a>.

requestFj sends every request with redirect: "manual" (ForgejoCli.ts:372) and treats anything outside 2xx as an error, so it never follows the rename. The link never gets a snapshot, and a link without a snapshot is always due in PullRequestSyncReactor, so every sweep reads it again.

I had 35 of these links sitting on 9 threads. In one hour of traces:

• ~1,290 Forgejo requests from PullRequestSyncReactor.sweep, nearly all of them this 301.
• Each link got read about 17 to 26 times an hour. The sweeps were taking 81 to 151 s, so they were spaced out more than a minute.
• That's on top of the ~640 an hour from branch PR lookups.

None of this showed up anywhere in the UI. I only found it because T3 kept getting slow, and I went digging through server.trace.ndjson.

Impact

Major degradation or frequent failure

Version or commit

0.1.7 (also checked main @ 25bf84a; same code)

Environment

Linux x64, headless t3 serve in Docker, self-hosted Forgejo, fj 0.6.0

Workaround

I relinked each thread with thread.pull-request.link (new repo, same PR number), then thread.pull-request.unlink on the old one. As soon as that landed, the 301s stopped and every link synced as merged.

What I think the fix is

Follow 301/302/307/308 in requestFj only when the Location stays on the same origin and under /api/v1/, with a small hop limit. That keeps the token on the same host, which I assume is why it's manual in the first place. Even better if the provider notices the repo moved and updates the link, so it doesn't pay for the redirect every time.

#31969 helps here too. It'd turn this from every sweep into a backoff that tops out at 15 minutes. It doesn't fix the link itself, though, so both seem worth having.