PR Checklist

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

AssetGroup.fetchFromNetwork() hash-validates a response, and then, if the response was
redirected, throws that validated body away and re-requests the redirect target:

const res = await this.cacheBustedFetchFromNetwork(req);

if ((res as any)['redirected'] && !!res.url) {
  // ...
  return this.fetchFromNetwork(this.newRequestWithMetadata(res.url, req), redirectLimit - 1);
}

The recursive call re-derives the canonical hash from res.url. That URL is the redirect
target, which is not a manifest entry, so cacheBustedFetchFromNetwork() takes its unhashed
branch and returns the second response without comparing it to anything. fetchAndCacheOnce()
then caches that second body under the original request.

So for a manifest-hashed asset served through a redirect, the body that ends up in the cache is
not the body that was validated. A server that answers the first request with the expected
contents and the second with different contents gets those different contents cached under the
original hashed URL, and ngsw.json's hash for that URL no longer describes what is stored.

This is reachable on a normal ng add @angular/pwa production build whenever a hashed build
artifact is served via a redirect — e.g. the app origin redirects its bundles to an asset host.

The reason this wasn't caught: every existing redirect test uses a URL with no manifest hash.
/redirected.txt and /lazy/redirected.txt are declared in asset group urls but are not files
in dist, so they never enter the hash table and the hashed-plus-redirected path is never
exercised.

What is the new behavior?

The original normalized URL is carried through the redirect recursion, so the body that is
ultimately cached is validated against the hash the manifest specifies for the URL it is being
cached under. A redirect whose target serves the expected contents behaves exactly as before; a
target that serves something else now fails hash validation like any other mismatch, and nothing
is cached.

Two tests are added to prefetch_spec.ts covering a hashed asset served through a redirect:
one where the target matches the manifest hash (must still cache and serve), and one where it
does not (must throw Hash mismatch and cache nothing). MockServerStateBuilder.withRedirect()
gains an optional body so the mock can model the browser behavior of following the redirect and
exposing the target's contents on the redirected response; the default is unchanged.

Verification:

• Full packages/service-worker/worker suite passes with the change (155 specs).
• The new mismatch test fails against unpatched main (no error is thrown, and the second body
  is cached) and passes with the change, so it genuinely covers the path.
• Checked in a real browser as well, using a stock ng new + ng add @angular/pwa production
  build whose generated loadChildren() chunk is served through a redirect: before the change the
  redirect target's second response is what lands in the SW cache under the app-origin chunk URL;
  after the change nothing is cached, while the legitimate case still caches the generated chunk
  and the lazy route loads normally.

Does this PR introduce a breaking change?

• Yes
• No

fetchFromNetwork() and cacheBustedFetchFromNetwork() gain an optional trailing parameter that
defaults to today's behavior. Both are internal to the worker.

Other information

The two existing redirect hardening advisories in this area address different state, and neither
covers this: GHSA-gv2q-mqqv-365m
preserves a caller's explicit redirect: "error", and
GHSA-qxh6-94w6-9r5p
strips sensitive headers on cross-origin redirects. This is about which body gets hash-checked,
under ordinary default redirect handling and with no special headers involved.

Happy to move this to a private advisory instead if the team would prefer to handle it that way.