fix(egress): retain executor controls until final wire sanitation

[diegosouzapw]

Root cause and fix

The shared pre-executor cleanup in #14252 correctly removed routing markers, but also removed native passthrough/tool-casing controls before their executor consumers. Codex consequently treated a native Responses request as translated input and dropped metadata through its non-native allowlist.

Separate consumed routing-marker cleanup from final wire cleanup. The pre-executor boundary still removes every _omniroute* field, including unknown future routing markers. Executor controls survive until their consumers; final stripInternalBodyFields behavior remains unchanged and strips all internal fields before serialization.

Evidence

• Exact base 373c31f reproduces native metadata loss.
• Temporary boolean-only tracing showed metadata present through dispatch but the native marker already absent at the executor. All instrumentation was removed; no diagnostic code remains in chatCore/codex.
• New boundary regression failed on the base because the native control was absent.
• After repair: 12 selected tests PASS, zero failures/skips, covering native Codex payload and final serialized marker absence, shared preparation, universal handoff, DefaultExecutor, Dario and NineRouter egress.
• Existing metadata assertion retained; added assertions prove native and future routing markers do not reach upstream.
• Prettier, scoped ESLint with frozen suppressions, diff check and full branch hooks passed. Existing asynchronous call-log cleanup warning is recorded; focused PASS is not full-suite acceptance.

Preserves the security intent of #14252 and its contributor's work. Draft recovery slice; full combined CI and protected-branch rollout remain pending.

[diegosouzapw]

Fechando como coberta pela #14511, mergeada na release/v3.8.51 (drenou as mesmas base-reds: genérico de stdio do auggie, imports do projectCombo, strip de _native*Passthrough e os guards de catálogo/prefixo/qwen/opencode/quota). O conteúdo que só esta PR tinha já entrou pelas #14501, #14503, #14508 e #14516. (merge-batch 2026-09-24)