Ferret pays a full-capacity reallocation via split_off(0)

### Root cause

`Vec::split_off(0)` in stdlib is:

```rust
if at == 0 {
return mem::replace(
self,
Vec::with_capacity_in(self.capacity(), self.allocator().clone()),
);
}
```

The `Vec::with_capacity_in(original_capacity)` allocates a brand-new buffer matching the source's original capacity, even though the new vec will be logically empty. Fires whenever `count == self.keys.len()` (or the receiver's `choices` / `macs`).

When the pool holds millions of entries, this reallocation becomes a non-trivial per-call cost on the consume path.

### Affected sites

- `crates/ot-core/src/ferret/sender.rs:263, 303` — `split_off` on `keys`
- `crates/ot-core/src/ferret/receiver.rs:286, 287, 327, 328` — `split_off` on `macs` / `choices`

Start in crates/ot-core/src/ferret/sender.rs at lines 263 and 303, then inspect the split_off calls in crates/ot-core/src/ferret/receiver.rs at lines 286-287 and 327-328. Trace the consume path when count equals the full keys, macs, or choices length and verify that the resulting empty vector no longer triggers a full-capacity allocation.

Written by the indexing model from the issue text.