…out (#1472 step 5) (#1487)

After #1481 the off-thread StreamingToolWatchdog was used for exactly one thing:
bounding opaque tool calls with a flat wall-clock budget. In that mode its two
shared Volatile fields were written once and never changed, so the 1s polling timer
only ever computed "has the budget elapsed since start?" — which is exactly what a
CancellationTokenSource timeout token does. (The "why is this volatile instead of
actor state?" smell.)

Replace it with a TimeProvider-driven timeout token — new CancellationTokenSource(
timeout, timeProvider) linked to the caller token — draining through the same
DrainToCompletionAsync helper self-monitoring tools already use. A budget trip is
converted to the same TimeoutException message; caller (turn/user) cancellation is
rethrown unchanged (preserves #1481). Per call, so a slow tool times out without
affecting siblings, and TimeProvider-virtualizable so tests stay deterministic.

- Delete StreamingToolWatchdog, ToolWatchdogBudget, ToolWatchdogResetMode — removes
  the volatile, the polling timer, and the dead ResetOnItem/FirstItem/InterItem
  machinery (review follow-up #13).
- Unify the two drain paths on DrainToCompletionAsync (review follow-up #11).
- Point SpawnAgentStreamingTests at the production drain instead of the watchdog
  (review follow-up #12).
- Opaque wall-clock timeout + concurrent independence are already covered at the
  pipeline level (FakeTimeProvider); add one test for the stream-without-a-completion-
  item contract; gut the watchdog unit tests, keeping the INetclawTool default-adapter
  test.

No behavior change: opaque tools still time out at the same wall-clock budget with the
same message and per-tool isolation; self-monitoring tools are untouched. The spec-of-
record ("Per-call liveness by tool class") already says opaque tools get one wall-clock
budget — only the mechanism changed.

Net: roughly -150 LOC. Part of #1472.