After a shard split, pending write/read batches for the deleted parent
shard would retry with exponential backoff for up to 30s per batch,
causing ~70s of client unavailability.

The fix detects when a batch's target shard no longer exists in the
shard manager (checked before each retry attempt). When detected, the
batch stops retrying and re-submits each operation through the normal
pipeline, which re-hashes keys and routes them to the correct child
shards. This reduces client recovery time from ~70s to sub-second.

Changes:
- Add Exists(shardId) to ShardManager interface
- Add ErrShardNotFound sentinel error
- Write/read batch retry loops check shard existence before each retry
- On ErrShardNotFound, batches invoke a reroute callback that
  re-submits operations to the batch manager (which routes to correct
  child shards based on key hash)
- Add PutCall.PartitionKeyOrKey() for correct shard routing of puts
  with explicit partition keys

Signed-off-by: Matteo Merli <[email protected]>

Add tests verifying that write and read batches correctly detect when
their target shard is deleted (e.g. after a split) and re-route
operations to child shards:

- TestWriteBatchRerouteOnShardDeleted: verifies write batch detects
  shard deletion and invokes reroute callback with all operations
- TestWriteBatchNoRerouteWhenShardExists: verifies normal retry
  behavior when shard still exists (no false reroutes)
- TestReadBatchRerouteOnShardDeleted: same pattern for read batches

Also rephrase log message from "Shard deleted" to "Shard was
split/merged" to avoid implying data loss.

Signed-off-by: Matteo Merli <[email protected]>