feat: add POST /append-batch and Store::append_batch

[kiil]

Stacked on #156 and #157. This branch contains their commits too. Only the last commit (feat: add POST /append-batch …) is new here, and I'll rebase once those land. It depends on #156 because a batch larger than the broadcast channel overruns every live follower on its own. Without that fix, followers silently drop most of the batch.

What it adds

POST /append-batch takes an NDJSON body with one frame per line (topic, optional meta, ttl, hash). It returns the stored frames as NDJSON, in order.

printf '%s\n' \
    '{"topic":"clip.add","meta":{"n":1}}' \
    '{"topic":"clip.add","meta":{"n":2},"ttl":"last:100"}' |
  curl --unix-socket ./store/sock --data-binary @- http://localhost/append-batch

Ordering and atomicity

Store::append_batch takes the append lock once for the whole batch. Under that lock it:

• assigns consecutive ids,
• stages every frame (stream plus indexes) in one fjall write batch,
• commits it,
• broadcasts the frames in id order.

So a batch is contiguous in the stream, no other append can interleave, and a reader sees all of it or none of it. A malformed line returns 400 and an invalid topic returns an error; either way nothing is stored.

Other details:

• ttl defaults to forever, as for a single append.
• last:n trims are scheduled once per topic per batch, not once per frame.
• insert_frame is split into add_frame_to_batch + note_indexed, so the single-frame path and the batch path share the same code.

Numbers (macOS, aarch64; 500k meta-only frames; 4 pipelined connections; includes #157)

frames per request	frames/s
1 (/append/{topic})	50k
10	229k
100	340k
1000	379k

For comparison, the store alone does about 230k/s with one append per frame, and main over HTTP does about 16k/s.

Checks

• New tests: test_append_batch (store level: ids, order, atomic reject) and test_handle_stream_append_batch (route, handler, ttl default, 400 on a bad line). test_follow_replays_frames_dropped_by_lag is extended with a 3000-frame batch.
• cargo test --release: 230 passed. Integration: 12 + 12 passed. tests/test_xs_nu.nu: passed.
• cargo clippy -- -D warnings and cargo fmt --check: clean.
• Live cat -f during load at batch 1, 100 and 1000 (up to 371k/s): 200,000 / 200,000 frames, no dupes, same order as the store.
• The docs example above was run against this build.

Open questions

• The endpoint name /append-batch. Content negotiation on /append is an alternative.
• No CLI or xs.nu command yet. Happy to add one if you want the endpoint.
• No cap on batch size. Batches larger than 1024 are lossless for followers thanks to fix: replay frames a lagged follow missed instead of skipping them #156, but a cap might still be wise for memory.