ci: shard node_compat tests into 2 parallel jobs

[bartlomieju]

Summary

• Split the node_compat CI job into 2 shards per OS (3 OS x 2 shards = 6 matrix entries), halving wall-clock time from ~20m to ~10m
• Uses the same CI_SHARD_INDEX/CI_SHARD_TOTAL env vars and round-robin filter_to_shard mechanism already used by specs and integration tests
• Report uploads are suffixed with shard index (report-linux-0.json.gz, report-linux-1.json.gz)
• Summary script merges shard reports, with fallback to the old unsharded filename for historical data

Test plan

• CI passes -- the node_compat workflow itself doesn't run on PRs (it's scheduled), but the Rust code change is exercised by the existing cargo test --test node_compat path
• Trigger a manual workflow_dispatch run to validate sharding end-to-end

🤖 Generated with Claude Code

[miracatbot]

Problem: the summary merge path blindly sums total/pass across shard reports while also overwriting duplicate results keys.

Why here: merged.results[key] = value will silently replace an existing entry if the same test id ever appears in multiple shard reports, but merged.total += shard.total / merged.pass += shard.pass still count both copies. That makes the metadata potentially inconsistent with the merged results object.

Impact: if sharding ever overlaps due to a bug, retry artifact mixup, or future shard-count changes, the monthly summary can overcount totals/passes while hiding the collision.

Ask: can we either assert that result keys are disjoint when merging shard reports, or recompute total/pass from the merged results object after merge? That would make the summary logic more robust to bad inputs.

[miracatbot]

Re-checked after the update: recomputing total/pass from the merged result set fixes the inconsistency I had called out in the shard-summary merge logic. This looks good to me.