Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:16sulzdtks is past its budget: trevato/forge: "a stalled issue frees itself > the builder that stalled it does not pick it again within the hour" fail… #4997

I changed test/crew-stalls.test.ts to remove two load-dependent inputs I found by reading, but I couldn't reproduce the failure, so it's unconfirmed that this fixes it. The file passes locally, including 12 runs with six busy-loop processes competing for the CPU. tsc is clean. The forge's check on this push is the real test.

The cause I suspect is that autonomyTick walks every autonomous repository, and the test's tick line depends on that whole walk finishing in time. Earlier tests' repos were still active in it, so their work could slow or break the tick that the "does not pick it again within the hour" test reads. Runs that an assignment queues are also created asynchronously, so a slow machine could land one after the test had already stalled or inspected the issue.

• Own repo only: before each tick, tick() switches every other repo's autonomy off, so only the repo under test takes the tick's time.
• Deferred work lands first: a new settle() helper waits for deferred work to land after each tick and before the later driveRepo call.

I left the source alone: the stall and shun logic in src/crew/stalls.ts reads only stored timestamps and the now it is given. I also did not pin a fake clock, because run timestamps come from SQLite's own clock.

To try it: bun test test/crew-stalls.test.ts.

Closes #4968

I changed test/crew-stalls.test.ts to remove two load-dependent inputs I found by reading, but I couldn't reproduce the failure, so it's unconfirmed that this fixes it. The file passes locally, including 12 runs with six busy-loop processes competing for the CPU. tsc is clean. The forge's check on this push is the real test.

The cause I suspect is that autonomyTick walks every autonomous repository, and the test's tick line depends on that whole walk finishing in time. Earlier tests' repos were still active in it, so their work could slow or break the tick that the "does not pick it again within the hour" test reads. Runs that an assignment queues are also created asynchronously, so a slow machine could land one after the test had already stalled or inspected the issue.

• Own repo only: before each tick, tick() switches every other repo's autonomy off, so only the repo under test takes the tick's time.
• Deferred work lands first: a new settle() helper waits for deferred work to land after each tick and before the later driveRepo call.

I left the source alone: the stall and shun logic in src/crew/stalls.ts reads only stored timestamps and the now it is given. I also did not pin a fake clock, because run timestamps come from SQLite's own clock.

To try it: bun test test/crew-stalls.test.ts.

I changed test/crew-stalls.test.ts so the stalled-issue tests no longer depend on timing. I never reproduced the failure, so this is a fix for the most likely cause. The tests pass locally (three runs, plus six parallel runs of this test) and tsc --noEmit is clean. I haven't seen the forge's check on this push yet.

The failing test is "the builder that stalled it does not pick it again within the hour". The issue gave no failure log, so I found the cause by reading the code.

Likely cause: stalled() in src/crew/held.ts clears an issue when a park note is newer than the issue's last run, compared with > on millisecond timestamps. On a fast machine a run and its park note can land in the same millisecond. That reads as "no word since", the issue stays held, and the test never sees picked.

What changed:

• stall() and tick() wait 2 ms first, so every run and note is strictly ordered.
• Before the final driveRepo, the test ends any run the tick queued. A leftover queued run would hold the issue as "running" and block the pick.

What I left alone: the comparison itself in src/crew/held.ts. A tie is only possible within one millisecond and the tests were the only place it showed, so I did not widen the change.