Reject HTTP redirects on filter list and resource downloads

[chrmod]

Summary

Harden the adblocker against redirect-based supply-chain attacks. Until now, every remote resource fetch followed HTTP redirects by default, which meant a compromised or hijacked origin (GitHub raw content, cdn.ghostery.com) could quietly redirect clients to an attacker-controlled host serving malicious filter lists.

• Extend the public Fetch type with an optional init argument and have fetchWithRetry pass { redirect: 'error' }, so all consumers going through FiltersEngine.fromLists / fromPrebuiltAds* now reject 3xx responses instead of silently following them.
• Apply the same { redirect: 'error' } option to the Node fetch calls in the daily assets/update.js resource-refresh script.
• Replace axios with native fetch in tools/stress-test-engine-update.ts (and drop the axios devDependency), again rejecting redirects explicitly.

The Fetch type change is backwards-compatible — callers passing globalThis.fetch or a narrower one-argument function remain assignable.

Test plan

• Run FiltersEngine.fromPrebuiltAdsAndTracking(fetch) against the real CDN and confirm the engine still initializes successfully
• Temporarily point one list URL to a server that returns a 301/302 and confirm initialization fails with a redirect error instead of loading the redirect target
• Run assets/update.js and confirm resources are refreshed without errors
• Run the stress-test tool and confirm it still downloads and validates lists via native fetch

[seia-soto]

I don't know if avoiding redirect at all without a flag would be useful because many lists from GitHub may contain redirect unintentionally (like to raw.github...). There should be more similar cases as well. There's a pattern that people often try to do higher level processing in path level levering CDNs.

Migrating from axios to fetch, I wouldn't mind using both despite the recent accident.

[seia-soto]

It should be "RequestInit" from built-in.

[philipp-classen]

Not following redirects of arbitrary resources blindly makes sense, but here the Ghostery Adblocker is download from Ghostery infrastructure. If an attacker can control it, they could directly serve malicious content. (There is not much to do in that scenario. The best that I could see would be to sign the resources and hope that attackers are not also able to fake those signatures.)

In other words, there is no compelling attack vector IMHO that justifies that we prevent redirects.

A side-effect in the PR is to replace Axios by native fetch. I do not mind, but it is a different topic. I would recommend to open a new one for that.