Weekly pacing aims at spending what's left by the reset, not at an even week: it must not idle the crew until Thursday #8898

Weekly pacing now reads burn against allowed instead of an even week's share. The 24 tests in test/week.test.ts, week-wiring, week-pump and week-hold pass, and bun x tsc --noEmit and bun scripts/gate.ts are clean. I did not run the full suite.

What changed in src/crew/week.ts:

• Status comes from the last 3 hours' burn against allowed, which is what's left above the reserve divided by the hours to reset. The even-week comparison and offPct are gone. The decision now carries allowedPctPerHour instead.
• Tolerance is now ±25% of allowed, where it used to be 5% of the week. It is a new value I picked, and WEEK.tolerance is where to change it.
• Burning over allowed slows the crew to ceiling × allowed / burn, never below 1 slot, and names when the reserve would run out. At or past the reserve it reads "ahead" and holds the crew at 0 slots.
• Burning under allowed lets slots rise to the ceiling. With idle builders and nothing startable it releases the next gated issue, one a look, through the existing releaseForPace.
• No burn read yet starts at unknownSlots (2) and says it will adjust within the hour.
• Spend already made no longer counts. Heavy use earlier in the week no longer slows a crew that is burning under allowed.

Tests: test/week.test.ts replays 2026-11-02. At 19:25Z, 46% free and 2.7 points an hour, it slows to 1 slot and says it runs out on the 3rd. At 20:45Z, 45% free and flat, it reads "behind", allows the full ceiling and releases. The other three week tests spent everything 24 hours back, so they now put some spend inside the burn window. Their expectations changed with the new reading: heavy spend with a high burn gives 1 slot, not 2, and the "Behind pace by 30%" sentence is now "Behind pace: 80% of the week left".

I did not add "offer the next bet" when under allowed. Only the gated-issue release exists today, and I kept it as the one lever. Offering a bet is a separate change.

The first push had a type error that I fixed in the later commits, so the branch has three commits.

Closes #8897

Weekly pacing now reads burn against allowed instead of an even week's share. The 24 tests in test/week.test.ts, week-wiring, week-pump and week-hold pass, and bun x tsc --noEmit and bun scripts/gate.ts are clean. I did not run the full suite.

What changed in src/crew/week.ts:

• Status comes from the last 3 hours' burn against allowed, which is what's left above the reserve divided by the hours to reset. The even-week comparison and offPct are gone. The decision now carries allowedPctPerHour instead.
• Tolerance is now ±25% of allowed, where it used to be 5% of the week. It is a new value I picked, and WEEK.tolerance is where to change it.
• Burning over allowed slows the crew to ceiling × allowed / burn, never below 1 slot, and names when the reserve would run out. At or past the reserve it reads "ahead" and holds the crew at 0 slots.
• Burning under allowed lets slots rise to the ceiling. With idle builders and nothing startable it releases the next gated issue, one a look, through the existing releaseForPace.
• No burn read yet starts at unknownSlots (2) and says it will adjust within the hour.
• Spend already made no longer counts. Heavy use earlier in the week no longer slows a crew that is burning under allowed.

Tests: test/week.test.ts replays 2026-11-02. At 19:25Z, 46% free and 2.7 points an hour, it slows to 1 slot and says it runs out on the 3rd. At 20:45Z, 45% free and flat, it reads "behind", allows the full ceiling and releases. The other three week tests spent everything 24 hours back, so they now put some spend inside the burn window. Their expectations changed with the new reading: heavy spend with a high burn gives 1 slot, not 2, and the "Behind pace by 30%" sentence is now "Behind pace: 80% of the week left".

I did not add "offer the next bet" when under allowed. Only the gated-issue release exists today, and I kept it as the one lever. Offering a bet is a separate change.

The first push had a type error that I fixed in the later commits, so the branch has three commits.