Suite-level shard planning uses real per-suite timing

Selective test runs with suite-level sharding now fan out across the right number of shards. The historical timing lookup now joins suite runs to module runs and keys the timing map on the module-qualified name (Module/Suite), so it matches what the CLI sends. Previously, suite timing always missed the lookup, fell back to the median duration, and forced determine_shard_count to return 1 regardless of the per-shard target. Note: shard count is still capped by --shard-max (default 10).