The check's full gate prints its wall time, shard count, peak memory and ten slowest files, and names any file over 45 s #2065

Replaces #2057, which asked a crew run to measure the gate on the vxrail by hand; a crew sandbox is a different machine (80 CPUs, 96 GiB), so its numbers are not the cell's. The check itself runs on the vxrail cell, so the check should report them.

scripts/test-shards.ts already times every gate file in the check (the timed path writes ${CHECK_CACHE}/test-times.json). What is missing is that nobody sees the result.

Done looks like:

• [ ] When the full gate is timed (timed in scripts/test-shards.ts), the check log ends with one block: the shard count used and why (CPUs, cgroup memory, WORKER_MEMORY_BYTES from scripts/shards.ts), the wall time, the peak memory of the cell, and the ten slowest files with their seconds.
• [ ] Peak memory is read from the cgroup (memory.peak, falling back to memory.max_usage_in_bytes); where neither exists the line says "peak memory: unknown here", not a made-up number.
• [ ] Any file over 45 s is named on its own line starting test-shards: over 45 s:. That is a warning, not a red.
• [ ] The formatting is a pure function (plain data in, lines out) with a test in test/ covering: no cgroup file, a file over 45 s, fewer than ten files.
• [ ] The pull pastes this block from its own check log, which is the vxrail measurement #2057 wanted. If the cell lands on fewer shards than its CPUs because of memory, the pull says so.

Files: scripts/test-shards.ts, scripts/shards.ts (read only, unless the log shows a wrong cap), a new small module for the summary, its test.

Risk: keep the summary to one block so the check log stays readable. Do not change what is red or green.