test(desktop): pin the context meter to a round that completes no tool

[OmarB97]

#332 moved the meter's sampling from tool completion to the provider's own
usage, on the grounds that a round which calls no tool reports nothing at all
under the old scheme. Its e2e could not show that. Every round the mock drives
calls a tool, so sampling per completed tool and sampling per API response
produce the same series — I said so in that PR rather than let the green tick
imply more than it proved. This is the test that was missing.

The turn now contains one round that names a tool the agent cannot have. That
name is rejected in conversation_loop before the executor is ever entered
(_invalid_tool_retries), so the round finishes a real API call, reports real
usage, appends a result saying the tool does not exist, and continues — with no
tool_start, no tool_complete, and therefore no orphaned tool card. It is a
branch on a string, so nothing about it is timing-dependent.

Three other mechanisms were considered and rejected. Malformed tool arguments
never reach the executor's block path — the loop validates argument JSON first
and either aborts the turn or silently re-issues the identical request, and the
streaming transport repairs them earlier still. A length continuation works
but injects a user message mid-turn and duplicates text into the final
response. A guardrail block halts the loop by construction, which fails the
"turn must continue" requirement outright.

Two supporting changes:

• The mock counted tool results across the whole conversation, not the turn.
  A second turn in the same chat therefore started already at the cap and
  collapsed to a single round — so the existing "still tracks a session the user
  typed" test was passing on turn-boundary events, not the mid-turn frames it
  was written to check. Anchoring the count to the last user message fixes it:
  that test goes from 2 readings to 16. Only this spec has multi-turn chats, so
  no other spec that shares the mock changes behaviour.
• The probe's served prompt count is exported rather than hardcoded. The
  usage schedule is a function of conversation length, so a literal in the spec
  would drift the moment the system prompt or tool list changes size. The
  expected value is formatted through the status bar's own compactNumber,
  because the gauge is what the user actually reads.

The evidence, which is the only reason this test is worth having:

with e38eacbffb      15k -> 18k -> 21k -> 24k   (t=3.0 / 4.4 / 5.6 / 6.0s)
with it reverted     FAILS — 18k never appears

18k is the round that completed no tool. Reverting only the three source files
of #332 and re-running turns the new test red on exactly that assertion, and
restoring them turns it green again. A test that passes either way would prove
nothing, so that check is the point of the change, not a footnote to it.

---

Local Desktop E2E was run at reduced machine load; the four other specs that share the mock were last exercised while other suites had the box at 46-79 load average and failed at boot with zero assertion failures, so CI is the authoritative check on those.