perf: wake the batch processor when a buffer nears capacity

[drake-nominal]

Core-crate change. Rebased onto main now that #320, #322 and #323 have landed; one commit.

Addressing the review concern first

The worry was that this risks double-unparking the processor thread. It does not, and cannot.
Thread::unpark stores a single token, not a counter. Verified directly rather than from memory:

after 2 unparks -> first park 1.125us, second park 505.015708ms
tokens accumulate: false

Two unparks leave one token. The first park_timeout consumes it and returns immediately; the
second waits its full timeout. Wakeups cannot queue up, and the processor cannot spin.

Chasing that concern did surface a real one that had not been flagged, so it was worth raising.

The real cost, and what changed because of it

max_request_delay bounds how often requests are issued — the post-flush park is what keeps
requests large. Waking the processor early spends some of that budget. Writing 200,000 points
through a 10,000-point buffer:

threshold	requests	median request size
none (main)	21	10,000
1/2 (what this PR originally proposed)	34	5,000
3/4	26	7,500
7/8 (what it now does)	22	9,000

At half capacity this issued 62% more requests at half the size — meaningfully more gRPC round
trips at the backend. That is a worse trade than the latency it bought, and it is what the earlier
3.6% throughput regression was really measuring.

At seven eighths the request shape is indistinguishable from not waking early at all, and the
regression is gone.

Results at the current threshold

Blocking latency, six interleaved rounds, max_request_delay=1.0s:

max_points_per_batch	main	this PR
6,480	3,878 us	1,817 us	2.13x
12,960	4,011 us	2,500 us	1.60x

Every sample of the new build beat every sample of the old in both rows.

	main	this PR
Sustained throughput	6.44 Mp/s	6.64 Mp/s (within noise)
Requests per 200k points	21	22

When it helps: whenever a buffer fills before the flush timer fires — a high write rate, or a
max_points_per_batch small relative to rate x delay. When it does nothing: when the buffer
never reaches seven eighths, which is the common case at the default 250,000 batch size with a
modest write rate.

Tests

Three deterministic unit tests on the threshold predicate — fires on the crossing write, does not
fire below it, and does not fire again once past it. Deliberately not timing-based: this repo
already has a flaky timing test (test_time_flush, ~3/30 on main) and I did not want to add
another.

🤖 Generated with Claude Code