Increase Alloy remote_write max_shards from 3 to 10

[timtalbot]

Summary

Increase max_shards from 3 to 10 on both control_room and workload
prometheus.remote_write queue_config blocks.

Context

max_shards=3 (set in #270) was too aggressive — workloads with high series
cardinality can't drain their queue fast enough with only 3 concurrent senders
per Alloy pod, causing repeated "Remote storage resharding" log spam and
delayed metric delivery.

max_shards=10 provides enough throughput for high-cardinality workloads while
still limiting the fan-in blast radius during recovery (10 shards × 8 pods ×
9 clusters = 720 max concurrent connections, down from 3,600 at default 50).

Test plan

• Verify no "Remote storage resharding" log spam on previously affected workload
• Confirm push latencies remain sub-second under normal load
• Verify control room Traefik stays stable under steady-state push traffic

[claude]

Claude finished @timtalbot's task —— View job

---

• Gather context and review guidelines
• Review the diff and changed file
• Submit PR review

Reviewed and submitted. Both remote_write blocks are updated consistently, the concurrency math checks out, and there are no concerns.

[claude]

LGTM. Both remote_write blocks (control_room and workload) are updated consistently. The math in the PR description checks out (10 × 8 × 9 = 720 max connections), which is a reasonable middle ground between the previous 3 and the default 50. No concerns.