Shed the keys the rate names, not the batch that contains them

[bjmeetsfo]

drop_percent is a per-key rate: command_is_dropped hashes the routing key,
and the single-command path refuses exactly that key. The batch path
refused the entire batch as soon as any one key in it hashed into the shed
range, so the rate an operator set per key arrived as 1-(1-p)^n per batch.

Measured over 2000 batches per row:

drop_percent   batch   keys shed   BATCHES refused
           1     100        1.0%             63.4%
           5     100        4.9%             99.5%
          10      50        9.9%             99.2%
          10     100        9.9%            100.0%

A 1% shed rate refused two thirds of hundred-key batches, and 5% refused
essentially all of them. The per-key rate was right the whole time; what
went out was every key that happened to share a batch with a shed one.

A shed key now gets its own slot with its own status, beside the results of
the keys that were kept. That is the shape a batch already has -- the
grouped path fills a missing slot with a per-response error inside an
otherwise-ok batch.

A batch with nothing left answers exactly as it did before, top-level
traffic_dropped and no responses, so the case that was already pinned by a
test keeps its contract. Only a batch with survivors changes, and only so
that the survivors are served.

Tests: a partly shed batch now reaches the network for the keys it kept,
which against an unroutable proxy is visible as a connection failure rather
than a refusal -- it fails on the unmodified code with "the kept keys were
never sent". Plus the shape itself: the rate is per key, and the chance a
batch contains a shed key climbs with its size.