Suite-level sharding now spreads work across shards as intended

For selective testing at suite granularity, shard plans were collapsing to a single shard because historical timing data was looked up by bare suite name instead of the module-qualified name the CLI sends. The server now matches timing by Module/Suite, so large test runs are distributed across the expected number of shards and can hit the configured per-shard duration target. This also prevents same-named suites in different modules from being conflated. Note: the maximum shard count is still capped by --shard-max, so raise that if you want a tighter per-shard target.