fix(compression): track only the recursion path in isStrictlySerializable (#13154)

[KooshaPari]

isStrictlySerializable() usa um seen que acumula a árvore inteira e nunca é desempilhado, então dois irmãos apontando para o MESMO objeto não-cíclico eram lidos como ciclo e o body era rejeitado. Esta PR troca o rastreamento para o caminho de recursão (try/finally), que é o critério correto para detectar ciclo.

objeto compartilhado (não-cíclico):  antes false  →  agora true
ciclo real (controle negativo):      antes false  →  agora false

Escopo — leia antes de fechar a #13154

O título anterior desta PR dizia "remove the isStrictlySerializable gate". Isso não é o que o diff faz, e o corpo anterior também listava undefined como causa corrigida. Medido na árvore desta branch:

isStrictlySerializable({body:{}, mode:"standard", options:{provider:undefined}})  →  false
isStrictlySerializable({a: new Date()})                                          →  false

O gate continua rejeitando undefined e Date. Como strategySelector.ts:519-528 monta workerOptions com 9 chaves sempre presentes, na prática quase toda chamada real tem pelo menos uma undefined — ou seja, o caminho comum da #13154 (compressão caindo inline no event loop) permanece.

Por isso: esta PR corrige o caso do sub-objeto compartilhado, que é real e tem teste vermelho-no-tip/verde-com-o-fix verificado por execução. A #13154 fica aberta para o caso undefined/Date.

A mudança em strategySelector.ts é somente comentário, sem alteração de comportamento.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[diegosouzapw]

Thanks for #13154. Holding — this goes a bit further than the bug.

The reported false negatives come from isStrictlySerializable sharing one seen set across siblings, so a repeated non-cyclic sub-object reads as a cycle. Removing the gate entirely means bodies that really can't be structured-cloned reach postMessage and only fail inside the worker.

The catch change also means a worker timeout now re-runs the same heavy compression inline on the event loop. The worker exists precisely to avoid that.

Could you instead fix the cycle detection (track the recursion path — add before descending, delete after), keep the timeout fallback returning the body uncompressed, and add a test with a shared sub-object and one with a real cycle?

[diegosouzapw]

Thanks for tracking down the isStrictlySerializable false-positive (shared seen set across
siblings) — that diagnosis is correct. Removing the gate entirely goes further than the bug
report though: it also lets a body with a genuine cycle reach postMessage, where it only fails
inside the worker, and the catch-block change means a worker timeout now re-runs the same
heavy compression synchronously on the event loop — the exact case the worker exists to avoid.
Could you instead fix cycle detection by tracking the recursion path (add before descending,
delete after) rather than dropping the check, keep the timeout fallback returning the body
uncompressed, and add tests for both a shared-non-cyclic-object case and a real-cycle case?