WhisperCppEngine enforces no prompt clamp, so its overflow behaviour contradicts the documented direction

[kiki830621]

Type

bug

Problem

Both Whisper-family engines declare .supported(maxTokens: 224), but only one of
them enforces anything.

WhisperKitEngine tokenizes, clamps with clampedPromptTokens (keeping the
prefix, per #164 design D4), and hands the pipeline an exact token array.
WhisperCppEngine passes the rendered string through verbatim as a CLI argument:

if let prompt {
    arguments += ["--prompt", prompt]
}

There is no tokenizer on that path — the context-calibration spec acknowledges
this ("a conservative character heuristic on the whisper-cli path") — so whenever
the character estimate undershoots the real token count, truncation is entirely
up to whisper-cli's internals. As a port of the same reference decoding
algorithm, it most likely keeps the suffix:

prompt_tokens[-(self.n_ctx // 2 - 1):]

which is the opposite of what #164 documents as the project's clamp policy.

Impact

• Two backends declaring the same 224-token capability behave differently under
  overflow, and one behaves opposite to the documented policy.
• The context-calibration sentence "the clamp SHALL preserve the highest-priority
  items" has no enforcement point and no test on this path
  (PipelineWiringTests' clamp test only exercises WhisperKitEngine).
• Narrow in practice — the character heuristic is meant to overestimate cost —
  which is why this is filed rather than fixed inside context 的 token 預算應是 per-model 參數而非全域寫死 200：7 個 engine 只有 2 個吃 prompt，其餘照樣截斷且照印 injected(N) #164.

Notes

• Interacts with Reorder PromptRenderer so the highest-value context lands nearest the decode boundary #174: if the renderer is reordered so names land at the tail,
  whisper-cli's suffix-keeping becomes correct for free, and the WhisperKit
  clamp is the one that would need to follow.
• Found by context 的 token 預算應是 per-model 參數而非全域寫死 200：7 個 engine 只有 2 個吃 prompt，其餘照樣截斷且照印 injected(N) #164 verify round 1 (logic lens).