fix(core): guard compression request admission - #13072

[Critical] The new provenance stamp ignores outputCountIsEstimated, so a locally-estimated output count can be reported as authoritative.

const newTokenCountIsEstimated =
  usedEstimatedVisibleDelta ||
  Boolean(opts.originalTokenCountIsEstimated) ||
  restorationChars > 0;

One of the two "provider" counts consumed by the branch above (lines 1535-1566) can be a local estimate: when the provider reports promptTokenCount but omits candidatesTokenCount/totalTokenCount, the code sets outputCountIsEstimated = true and compressionOutputTokenCount = estimateSummaryOutputTokens(...) (lines 1296-1300), and the branch only requires typeof compressionOutputTokenCount === 'number' && > 0. newTokenCountIsEstimated then omits that third estimated source, so with an authoritative baseline and no restoration attachments it computes false and stamps a partly-estimated newTokenCount as exact.

The merge base hardcoded newTokenCountIsEstimated: true on this return, so this is a regression rather than a pre-existing gap. Consequence: tryCompress stores the value as non-estimated (llm-chat.ts:2772-2775), the banner drops the ~ prefix, and the threshold/session-limit gates later trust a number that contains an estimate.

Fix: fold the flag in — usedEstimatedVisibleDelta || outputCountIsEstimated || Boolean(opts.originalTokenCountIsEstimated) || restorationChars > 0; — and add a test with usage: { promptTokenCount: N } only, asserting newTokenCountIsEstimated === true.

[Suggestion] The cache-sharing admission estimate uses the raw char/4 estimator, not the UTF-8-adjusted one the cold path uses.

sharedCurrentRouteTokenEstimate is built from estimateContentTokens(...), while the cold path's sibling term is estimateUtf8AdjustedContentTokens(...) at line 663 (and the pre-hook shared estimate at line 639 has the same raw shape). This is the only local term protecting the unslimmed, largest request when the provider anchor understates the current route — the scenario the new "stale provider anchor" test targets — yet for non-ASCII content it is roughly 5× below the calibrated estimate (0.25 tok/char vs 1.25). That is the multilingual-bypass class this PR set out to fix, and the only test for this term uses ASCII.

Failure is bounded (the shared request 400s, is caught, and the slimmed cold path runs), hence a Suggestion: use estimateUtf8AdjustedContentTokens(sideQueryHistory, slimmingConfig.imageTokenEstimate) for the current-route term at both 639 and 1095.