"pillars > merged pulls of the last 7 days count by the pillar of the issue each closes, on the board and in the map's data" passes every time on a loaded check machine #5452

I pinned the merged-pulls case to one fixed instant, but I never reproduced the failure, so I haven't confirmed that's the cause. The type check is clean and test/pillars.test.ts passes (14 tests). I ran the whole file 15 times over with six busy loops loading the machine, and every run passed.

The -t command in the issue can't pass on any machine. The tests in test/pillars.test.ts build on each other, and -t skips the ones that create sandbox, parts and the rest. The case then dies with closes.number undefined. So I used whole-file reruns to check it.

What changed (test only):

• The case now takes T = Date.now() once.
• It sets merged_at on every pull explicitly: the fresh merges a minute before T, and the "verdict" pull ten days before.
• It reads pillarView(db, repo, new Date(T)) at that same instant.
• The board and map assertions are unchanged: same counts, no sleeps, no retries, no longer timeouts.

What I left alone:

• The board and the map's /api/v1/repos/:owner/:name/map endpoint still read the real clock, so they were not pinned. Their window is 7 days and the old pull is 10 days back, so a day boundary can't flip the result.
• No product change, because I found no product cause.
• The lead in the issue (the 7-day window crossing a day boundary under load) doesn't fit this test, which has no boundary near its data. The real cause may be elsewhere: the issue has no failing log, and I didn't have #5392's.
• If it fails again on the check machine, the log from that run is what's needed.

Closes #5410

I pinned the merged-pulls case to one fixed instant, but I never reproduced the failure, so I haven't confirmed that's the cause. The type check is clean and test/pillars.test.ts passes (14 tests). I ran the whole file 15 times over with six busy loops loading the machine, and every run passed.

The -t command in the issue can't pass on any machine. The tests in test/pillars.test.ts build on each other, and -t skips the ones that create sandbox, parts and the rest. The case then dies with closes.number undefined. So I used whole-file reruns to check it.

What changed (test only):

• The case now takes T = Date.now() once.
• It sets merged_at on every pull explicitly: the fresh merges a minute before T, and the "verdict" pull ten days before.
• It reads pillarView(db, repo, new Date(T)) at that same instant.
• The board and map assertions are unchanged: same counts, no sleeps, no retries, no longer timeouts.

What I left alone:

• The board and the map's /api/v1/repos/:owner/:name/map endpoint still read the real clock, so they were not pinned. Their window is 7 days and the old pull is 10 days back, so a day boundary can't flip the result.
• No product change, because I found no product cause.
• The lead in the issue (the 7-day window crossing a day boundary under load) doesn't fit this test, which has no boundary near its data. The real cause may be elsewhere: the issue has no failing log, and I didn't have #5392's.
• If it fails again on the check machine, the log from that run is what's needed.