fix(cache): private routes served from a public cache + bypass hardening

[JonasJesus42]

Split out of #510 at review request — none of this depends on anything else, it stands on its own, and it can
land without waiting on the CDN feature review.

These are all bugs already in production today. They were masked by every response shipping
CDN-Cache-Control: no-store: harmless while nothing caches in front of the Worker, and a cross-user leak the
moment something does (Workers Cache, a CDN rule).

1. Private routes falling into a public cache

PRIVATE_PREFIX_RE covered a short list, was case-sensitive, and was anchored at the root. Anything that
didn't match fell through to the listing default — public, 120s edge:

/listadedesejos, /wishlist, /favoritos, /orders, /order-placed, /profile, /perfil, /logout,
/sair, /cadastro, /signup, /register, /assinaturas, /troca, /devolucao — and also /Checkout
(capitalized) and /pt/checkout (locale prefix).

Rebuilt from a PRIVATE_SEGMENTS list, case-insensitive, tolerating a locale prefix.

2. hasOnlySafeCookies was fail-open

A response that has a set-cookie whose names the parser failed to extract was treated as safe, i.e.
cacheable. The parser's fallback path is documented in the code itself as unreliable, and the two outcomes are
not symmetric: guessing "safe" caches a personalized response into the shared entry. Now fails closed.

3. bypassPaths replaced the defaults

A site passing bypassPaths to add a path silently lost /deco/, /live/ and /.decofile. Now always
merged.

4. CDN-Cache-Control decided in one place

Previously a dozen bypass call sites each decided for themselves: some deleted the header, some didn't, and
several still emitted the profile's public Cache-Control (public, s-maxage=900) on the way out. Branches
returning before the cache layer (?asJson, ?renderJson, proxy, redirects) emitted nothing at all.

Now, at the single exit: a bypass forces no-store, an absent header defaults to no-store, and a value the
cache layer already decided is left alone. An early return can only ever be more restrictive, never
accidentally public.

5. Site configuration: free to tighten, noisy to loosen

Adding a restriction is always safe; removing one is what leaks user data. So:

registerPrivatePaths(["/listadedesejos", "/trocas"]);   // new — can only restrict

• registerCachePattern still wins over the built-ins, except that it can no longer make a private path
  public — a broad site pattern was capturing /checkout.
• setCacheProfile("private", { isPublic: true }) is refused with a warning. allowPublicPrivateProfile() is
  the escape hatch, and it has a name you have to type.

6. The VTEX middleware overwrote Cache-Control on every response

It wraps handleRequest, so it runs after the whole cache layer and is the last writer of the header —
including on a HIT. It downgraded a home page from s-maxage=900 to vtexCacheControl's generic
s-maxage=60.

It now only speaks up for the case it genuinely knows better about (logged-in or custom pricing) and, when it
does, clears CDN-Cache-Control too — otherwise a response goes out as private, no-store alongside
public, max-age=300, and Cloudflare gives the latter precedence.

Also

Warns at boot when buildSegment is missing, since the logged-in bypass reads segment.loggedIn and is inert
without it — authenticated and anonymous visitors then share one entry.

Validation

2553 tests passing. Typecheck clean across the three packages. Also verified against a real built site's
worker: /listadedesejos, /Checkout and /pt/minha-conta now come back private, no-store; they were
public listing before.

The 4 failures in draft preview (workerEntry.test.ts, nextjs/draftShell.test.ts) are pre-existing on
main — confirmed with git stash.

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 7.56.0 🎉

The release is available on:

• blocks-v7.56.0
• GitHub release

Your semantic-release bot 📦🚀