fix(shard-distributor): make DeleteShardStats non-transactional and fix cleanup condition

[AndreasHolt]

What changed?

• Updated DeleteShardStats to batch deletions into chunks (size 64) to stay under the etcd transaction limit (128 ops), while preserving the leader guard for safety.
• Fixed a bug in the runShardStatsCleanupLoop where it was checking len > 0 instead of len == 0, causing it to skip cleanup when stale stats were actually present.

Why?

• Batching: Shard stats cleanup may involve many keys. Writing them in a single transaction can risk exceeding etcd's 128-op limit.
• Loop Fix: The previous logic inverted the check, meaning cleanup only ran if there was nothing to clean, effectively disabling the feature.

How did you test it?

• Added TestDeleteShardStatsDeletesLargeBatches to verify batching behavior.
• Unit coverage already present for the processor/store and running the canary service.

Potential risks
If a leadership change occurs in the middle of processing multiple batches, the operation will fail. The remaining stale stats will simply be picked up and cleaned on the next periodic tick of the cleanup loop.

Release notes

Documentation Changes

[eleonoradgr]

I think removing the guard we are going to have several concurrent delets, that are going to result in errors and create a lot of noise in logs and metrics

[AndreasHolt]

I’ve updated the implementation to keep the guard on these deletions. They are now processed in batches (for now of 64) to satisfy the etcd transaction limit. Every batch is guarded to prevent concurrent deletes and log noise