Count fixed request overhead in context calibration so compression doesn't underestimate

[uuzzrm]

Found this while tracing why compression sometimes kicks in later than it should.

The calibration in ContextManager works like: estimate the messages in chars, scale by (real prompt_tokens / estimated) from the last API call. Problem is, the API bills for the system prompt and tool schemas on every request, and those aren't part of messages — so the ratio quietly absorbs that fixed overhead. That's fine while the conversation is long, but after layer 2/3 compression shrinks the message list, the fixed overhead becomes a much bigger share of the real usage. The ratio is then too big for the remaining text, measure() underestimates by 10% or more, and the 70%/90% thresholds fire late — right around where a provider's hard limit lives.

Fix: the agent registers its system prompt + serialized tool schemas as explicit fixed overhead (ContextManager.setFixedOverhead), and observe/measure count it on both sides of the ratio. The ratio stays a pure chars-per-token rate, so shrinking the conversation doesn't change what it means.

Tests:

• fixed overhead is counted in observe/measure
• measure stays honest after the conversation shrinks (this is the actual bug — without the fix it reads ~12 instead of ~210 after compression)
• without setFixedOverhead the estimator behaves exactly as before
• an agent with empty history still measures its fixed overhead

4 new tests, full suite passes.