Auto mode classifier stops at its deadline on rate limits and tells the model how long to wait

What

Auto mode uses a classifier, a separate model call that reviews each action before it runs. This release changes how that classifier handles rate limits. A rate limit is when the API answers "too busy, try again after a while", and the wait it asks for is called a retry-after.

• sideQuery, the helper that makes these background model calls, takes a new retryAfterBudgetMs option. If a 429 or 529 response asks for a wait at least as long as the time left before the deadline, the response is marked x-should-retry: false and tagged with an internal x-cc-retry-after-too-long header. The call then fails instead of sleeping past its deadline. The internal header is removed before the error is shown. Before, any retry-after was honoured.
• The classifier passes this budget only when rateLimitFailFastEnabled is true in the tengu_auto_mode_config remote configuration.
• When the second-stage classifier call fails with a retry-after, the reason given to the model now says how long the API asked to wait and not to retry before then. It says the denial is not a safety judgment and tells the model not to retry or try other reviewed actions until the wait is over. For long waits it adds: stop and tell the user. Before, it always said the error was "usually transient" and that retrying often succeeds.
• The classifier result now carries retryAfterMs, which is passed to the code that writes the denial message, and the outcome record gains retryAfterBucket.
• The classifier's outer retry loop now stops as soon as the result carries retryAfterMs, and its check for results that must not be retried now reads the current result.
• server_thread_unsupported is now treated as a temporary failure with no verdict.
• A user message holding a single tool result can now carry classifierBoundary: true. When the conversation is prepared for the classifier, the action whose result is marked this way starts a new text segment. The mark is saved with the message, so it is kept even when only the stored transcript is available. The classifier call also takes one extra argument.

Why

Under rate limits, an action no longer has to sit blocked waiting on a classifier that cannot answer in time, and the model is no longer told to keep retrying a service that has asked it to wait. Nothing has been read about rateLimitFailFastEnabled, so whether the fail-fast part is active is unknown.