v1.29.0 — @harperfast/prerender-browser

Cache public sub-resources that also carry Set-Cookie

The resource cache refused to store any response carrying Set-Cookie. But set-cookie is
already in NON_REPLAYABLE_HEADERS, so filterReplayHeaders strips it from every replay — the
store-side refusal protected nothing the replay path did not already, and cost nearly the entire
cache.

Measured on a CDN-fronted storefront, where the edge staples Set-Cookie onto every response
including immutable content-hashed bundles served public, max-age=31536000: the gate refused
99.8% of otherwise-cacheable CSS/JS (1,740 stores against 1,047,917 misses fleet-wide), holding
the hit rate at 13.7% that never rose because the cache never filled.

Set-Cookie is now ignored only when the response is explicitly cache-control: public. Without
public, the conservative refusal stands. All other refusals are unchanged.

Live verification, cold vs warm, content identical in all four arms: PDP 44%, catalog 86% warm hit
rate. Only component code is cached — CACHEABLE_RESOURCE_TYPES is stylesheet/script only, so
the XHR/fetch responses carrying page data are never stored.

PR #175.