fix: keep the cart and the product rating alive when a dependency fails

[marcoferreiradev]

Duas correções de carrinho no fork, todas de erro medido em produção. Sobe junto com deco-sites/oficina-reserva#784, que já pina esta branch.

Rebaseada em main-alt hoje: antes disso o pin do site revertia o deco-cx#790 (o content-type das avaliações), porque dd0cafb2 não descendia de cdfe1bd6.

1. orderFormId do cliente quando o cookie atrasa — vtex/actions/cart/updateAttachment.ts

updateAttachment resolvia o carrinho só pelo cookie checkout.vtex.com, que é HttpOnly e chega atrasado: na sessão fria ele só é setado pelo getCart que acabou de rodar, e as escritas que vêm logo atrás saem antes. 3.354 erros em 6 dias, o maior grupo da loja. A VTEX endereça o orderForm pelo path param, então o cookie é opcional para a escrita — ele continua vencendo quando existe, e o props.orderFormId só entra quando falta. O throw fica: id genuinamente ausente ainda precisa falhar, senão a fila grava um carrinho vazio por cima do real.

2. CHK0038 não derruba mais o carrinho inteiro — vtex/loaders/cart.ts

O getCart re-posta marketingData para ecoar atribuição que a VTEX já guardou. Quando uma audiência de campanha injeta marketingTag nula (bug conhecido deles), o eco volta 400 CHK0038 e o erro subia, derrubando o getCart inteiro — 143 erros em 6 dias, em todo pageview dos carrinhos afetados. O eco é no-op no sucesso, então falhar nele não perde nada: serve o carrinho já buscado e avisa.

⚠️ Nunca sanear marketingTags para contornar — a PR deco-cx#352 fez isso, apagou o gatilho da promoção e machucou vendas.

Retirado da PR após revisão

• verified-reviews/ volta ao contrato do main-alt: ratings e fullReview devolvem o resultado tratado em vez de lançar. Devolver o vazio numa falha grava esse vazio no cache do loader, mas por pouco tempo (CACHE_MAX_AGE_S=180, e todo deploy zera o cache). Lançar quebrava o contrato 200 de quem consome, inclusive o app mobile no /live/invoke do fullReview. O retry de corpo vazio também sai: nunca foi provado que a segunda tentativa resolve.
• stripNulls no Seo.tsx sai: no site da Oficina não fazia nada (o JSON-LD de produto não passa por este componente), e o erro do iOS que ele mirava parou em 11/09, antes dele existir.

---

deno fmt, deno lint e deno check **/mod.ts verdes (hook de pre-commit).

🤖 Generated with Claude Code

[marcoferreiradev]

Terceiro commit: Seo.tsx — tira os nulls do JSON-LD antes de serializar

O scanner de schema do Apple Wallet, no iOS Safari, percorre o JSON-LD da página chamando hasOwnProperty.call(node, "telephone") em todo nó, e estoura quando o nó é null. As PDPs publicam seo.description: null — JSON.stringify mantém null e só descarta undefined — então o scanner quebrava em ~104 erros de client por semana, todos iOS, todos em página de produto.

schema.org não atribui significado a propriedade com valor nulo, então removê-las é sem perda para consumidores e é schema melhor para o Google.

Verificado em isolado antes de commitar:

seo.description: null      removido
null dentro de array       removido (itemListElement cai de 3 para 2)
0, "" e false              PRESERVADOS  ← a armadilha do falsy

Encadeado antes do escape de </script> que já existia, não no lugar dele: as duas proteções valem para o mesmo payload.

O pin do site já aponta para dd0cafb2 (deco-sites/oficina-reserva#784).