Shared-cache renders that redirect return 500 "Too many redirects" since #3168

Description

Any route whose shared-cache render responds with a redirect (e.g. an auth gate that redirects unauthenticated visitors to a login page) returns 500 with TypeError: Too many redirects since #3168 (35af7910).

A stock Payload CMS app is a reliable reproducer: /admin redirects unauthenticated visitors to /admin/login.

Repro

1. Payload CMS 3 app on vinext (current main), Cloudflare platform, cdnAdapter workers cache, D1/KV/R2 bindings, no admin users created yet.
2. GET /admin → 500 (plain Internal Server Error body).
3. Worker logs show the same render repeated ~20 times, then:
   复制

   TypeError: Too many redirects.<original url>?...__vinext_cache_key=..., /admin/login?redirect=..., /admin/login?redirect=..., ... (20 hops)

On 80c5f590 (commit before 35af7910) the same request correctly returns 307 -> /admin/login and the login page renders.

Analysis (from instrumentation on a deployed repro)

• Public traffic enters the cache-fronted response entrypoint directly.
• On a cache miss the render returns 307 -> /admin/login (Cache-Control: no-store, nothing cached).
• A fetch through the cache-enabled entrypoint follows redirects by default; the follow-up request re-enters the entrypoint with the redirect target URL — but the response-stage invocation/props still describe the original URL (verified: every hop rendered with the original requestUrl while the entrypoint received the login URL).
• The redirect source re-renders and redirects again until the runtime's redirect budget is exhausted.

Two contributing defects: the cache-facing fetch follows redirects, and the invocation props appear stale across those internal redirect hops. The first is enough to restore correct behavior: serve the redirect to the client instead of following it.

Fix

Proposed in #3242 (redirect: "manual" on the cache-facing request). Happy to dig into the stale-props transport as a follow-up if maintainers want that fixed too — happy to be assigned this issue.