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.?...__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.

Start at the cache-fronted response entrypoint and inspect the cache-facing fetch described in the issue, then run the Payload CMS reproduction or request a redirecting route on the Cloudflare setup. Verify that the redirect is returned to the client as 307 rather than followed internally, and that the login page renders without a redirect loop.

Written by the indexing model from the issue text.