feat(vtex): forward the full request cookie for session-scoped account reads and writes

[marcoferreiradev]

Why

parseCookie forwards only the VtexId cookies and drops vtex_session. store-graphql's
@withCurrentProfile resolves the profile from that session — so without it, every account
loader/action resolves the cookie holder instead of the session-scoped shopper.

That makes telesales impersonation impossible: an operator browsing on a customer's behalf
carries an admin token plus a session that names the customer, and these nine endpoints only
ever saw the admin.

What changed

New forwardCookie(headers) in vtex/utils/vtexId.ts returns the full request cookie. The
nine account loaders/actions below now use it in place of parseCookie().cookie, matching the
cookie forwarding the cart actions already do inline:

kind	files
loaders	user.ts, profile/getCurrentProfile.ts, address/getUserAddresses.ts, payment/userPayments.ts
actions	profile/updateProfile.ts, address/{create,update,delete}.ts, payment/deletePaymentToken.ts

parseCookie is still used for the JWT payload (sub, userId) — only the forwarded cookie
string changed. The forwarded cookie is what targets the write; no request field does.

10 files, +46/−20.

Known risks, deliberately not addressed here

Both were found by review and left alone on purpose — this app should change as little as
possible, and neither is reachable-and-harmful today.

1. A stale session can now resolve to null where it previously fell back to the cookie.
   In withCurrentProfile, session takes precedence, and getCurrentProfileFromSession only
   throws when !session || !session.id — a valid session without a profile returns
   currentProfile: null successfully, so the cookie fallback never runs. Before this change
   getSession always threw (no vtex_session forwarded) and the fallback always ran.
   Reachability of that window is unproven; an ordinary logged-in shopper was verified live
   through these endpoints with the change active. If it ever bites, the targeted fix is to
   gate forwardCookie on payload.audience === "admin", which comes from the signed JWT.

2. newsletter/updateNewsletterOptIn still subscribes with the cookie holder's email.
   It is not in the nine, and under a telesales session it would name the operator. Left as-is
   because it is inert: checkUserAuthorization gates the write on storeUserAuthToken, which
   an operator's admin token is not, so the mutation is a silent no-op with either email —
   fixing it changes no observable behaviour and would add a round-trip plus a throw path to an
   endpoint with no consumer.

Downstream

oficina-reserva on feat/callcenter-operator pins this branch at deno.json:48. The pin
points at a commit that exists only on this branch, so the site build depends on this landing
on main-alt and being repinned to the merged SHA.

🤖 Generated with Claude Code