A conversation turn that hits a rate limit rests the account that served it, as a run does #8222

A conversation turn that the provider rate-limits now rests the account that served it, the way a run does. bun scripts/gate.ts, tsc --noEmit and test/conversation-turn.test.ts pass. The new test fails when src/crew/conversation.ts is reverted.

What changed (src/crew/conversation.ts)

• When a turn's result is rate-limited (isRateLimited), a new restAfterLimit reads resumeAt and limitOf from the result. It then calls noteLimit and restSubscription with them, as runner.ts does.
• The person gets one line, <account> is resting until HH:MM UTC., in place of "I could not answer that just now". The provider's own words never reach the person. They are stored only in the account's rest note and standing, as a run's are.
• No other change was needed for the refusal. The existing pickSubscription check in begin already answers resting while the account rests and no other grant is awake, and it starts normally once the account wakes or another grant is awake.
• A turn on the forge's own token (no grant) has no account to rest. It notes the window against the platform and says "The account is resting until …", the same as a run's platform path. I did not add a rest for it.

Test (test/conversation-turn.test.ts)

• A stub claude answers a session limit. The test checks the rest is set, the 5h window is noted, and the stored line has no provider text.
• A second message is refused with resting, and nothing is stored for it.
• After wakeSubscription, the next message starts normally and is answered.

I did not add a "take over with another grant" path inside the turn. The next message simply picks a different awake grant.

Closes #8212

A conversation turn that the provider rate-limits now rests the account that served it, the way a run does. bun scripts/gate.ts, tsc --noEmit and test/conversation-turn.test.ts pass. The new test fails when src/crew/conversation.ts is reverted.

What changed (src/crew/conversation.ts)

• When a turn's result is rate-limited (isRateLimited), a new restAfterLimit reads resumeAt and limitOf from the result. It then calls noteLimit and restSubscription with them, as runner.ts does.
• The person gets one line, <account> is resting until HH:MM UTC., in place of "I could not answer that just now". The provider's own words never reach the person. They are stored only in the account's rest note and standing, as a run's are.
• No other change was needed for the refusal. The existing pickSubscription check in begin already answers resting while the account rests and no other grant is awake, and it starts normally once the account wakes or another grant is awake.
• A turn on the forge's own token (no grant) has no account to rest. It notes the window against the platform and says "The account is resting until …", the same as a run's platform path. I did not add a rest for it.

Test (test/conversation-turn.test.ts)

• A stub claude answers a session limit. The test checks the rest is set, the 5h window is noted, and the stored line has no provider text.
• A second message is refused with resting, and nothing is stored for it.
• After wakeSubscription, the next message starts normally and is answered.

I did not add a "take over with another grant" path inside the turn. The next message simply picks a different awake grant.

All three review points are fixed on the same branch and pushed. bun scripts/gate.ts, tsc --noEmit and 105 tests across the conversation, limit and pause suites pass. scripts/fast.ts named 1110 test files for this diff because it touches runner.ts. I ran only the suites that mention limits, rests or isRateLimited, so the forge's full check is still to run.

• Provider words: a rate-limited turn now removes the streamed copy of the limit message before it adds its own line. It drops any streamed agent turn that equals the result or contains its first line. The test stub now emits the limit as an assistant text event ahead of the result, and the tests assert that no stored turn contains session limit.
• Platform path: the line now reads "The forge's own model window is full until HH:MM UTC; try again then." I did not refuse the next message, because nothing rests; it is accepted. A new test covers the line, the noted 5h window on the platform, and the accepted follow-up.
• Shared helper: takeLimit in src/crew/limits.ts takes the first line of the provider's message, reads the reset time and window, notes the window, and rests the account when one is given. Both runner.ts and conversation.ts call it, and the run's behaviour is unchanged. limits.ts now imports from core/standing.ts and core/subscriptions.ts.

I put takeLimit in limits.ts rather than standing.ts, because it needs restSubscription and resumeAt.

Nothing is pushed. I made no changes, because the three failures look like timing flakes under the check's load, not something this pull caused.

All three failing tests pass on this branch locally:

• test/mcp.test.ts and test/checks.test.ts pass (89 tests), including "map and wait_for are the plan's own actions" and "a check in flight when the forge stops…".
• test/apps-proxy-overhead.test.ts passes, as does test/conversation-turn.test.ts, which covers this pull's code.
• bun scripts/gate.ts is clean.

None of the failing tests touch the files this pull changes (src/crew/conversation.ts, limits.ts, runner.ts). The proxy test is a latency measurement (median under 5 ms, p95 under 20 ms). The "check in flight" test took 30 s of a 535 s run spread over 57 shards, so a loaded machine would explain both.

I didn't run bun x tsc --noEmit in this session, and scripts/fast.ts called the diff too broad to name tests (it reached 1110 files). I picked the suites above by hand.

The forge needs to re-run the check on this branch. I can't trigger it without a new push, and I have no change to push.