perf: add enqueue_many so a wide record takes one buffer lock, not one per channel

[drake-nominal]

Stacked on #320. Core-crate change — additive, no existing signature changes.

What it does

Writing N channels at one timestamp took N capacity reservations and N buffer lock acquisitions,
one per channel, though they all belong in the same request. enqueue_many admits the batch under
one reservation and one lock.

Oversized batches are admitted in pieces capped at max_points_per_record, so one call can neither
build a request larger than that limit nor hold the buffer lock longer than a record's worth of
work. has_capacity deliberately lets an oversized batch into an empty buffer — correct for a
single channel's series, but wrong for a batch assembled from thousands of channels, where nothing
else bounds it. A batch that already fits is admitted whole, so a wide record keeps the guarantee
that its channels share a request, and one channel's series is never split across requests.

Results

Against the staging backend, on top of #320, 6,480 channels at one timestamp, interleaved A/B
over three rounds:

	#320	+ this PR
CPU per million points	0.487 s	0.437 s	~10% less
Throughput	2.12 Mp/s	2.17 Mp/s	within noise

Throughput is unchanged because staging is network-bound at this rate — the win here is CPU. Set
expectations accordingly: this is a modest, real improvement on top of #320's 4.6x, not another
multiple.

Tests

Three new unit tests: every channel of a wide record lands in one request; an oversized batch is
split with no request exceeding max_points_per_record and no points lost; and a channel reached
through both enqueue and enqueue_many shares one series rather than splitting.

🤖 Generated with Claude Code