MUL-7816 fix(taskfailure): classify a 403 usage limit as provider quota, not auth

[drakeo338]

What does this PR do?

Refs #8965. Covers the item where a 403 usage-limit failure is filed as an auth failure.

On "API Error: 403 You've reached your 5-hour usage limit" the bare 403 auth rule matched first, so members were told to fix valid credentials. Classify now checks "usage limit" before it and returns the quota reason; a plain 403 stays auth.

Related Issue

Refs #8965

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Refactor / code improvement (no behavior change)
• Documentation update
• Tests (adding or improving test coverage)
• CI / infrastructure

Changes Made

• server/pkg/taskfailure/classify.go and classify_test.go

How to Test

go test ./pkg/taskfailure/ in server/: 198 passed, 3 failed before, 201 passed after.

Checklist

• I have included a thinking path that traces from project context to this change
• I have run tests locally and they pass
• I have added or updated tests where applicable
• If this change affects the UI, I have included before/after screenshots
• I have updated relevant documentation to reflect my changes
• If I added a new runtime / coding tool / UI tab, I synced the change to landing copy (apps/web/features/landing/i18n/) and relevant docs (apps/docs/content/docs/)
• If this PR touches Chinese product copy, I checked it against apps/docs/content/docs/developers/conventions.zh.mdx (terminology, mixed-rule for task / issue / skill)
• I have considered and documented any risks above
• I will address all reviewer comments before requesting merge

AI Disclosure

AI tool used: Claude Code
Prompt / approach: Reproduced with a failing test, then a minimal ordering fix.

Screenshots (optional)

[vercel]

@drakeo338 is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.

[Bohan-J]

Thanks for the focused fix. The diagnosis is right: on current main, API Error: 403 You've reached your 5-hour usage limit lands in agent_error.provider_auth_or_access because the bare 401/403 rule runs before the quota rule. Keeping this PR classification-only is the direction we want. Two things need to change before merge.

1. Older daemons keep reporting auth. Classification runs on the daemon, and the server only reclassifies when the reported reason is empty (FailTaskWithTransition). A daemon built before this PR sends a non-empty agent_error.provider_auth_or_access, which the server persists as-is, so users see no change until their daemon upgrades. Please add a matching rule to NormalizeDaemonReason, the way #8200 did for the concurrent-request-limit case.

2. The Failed to refresh access token. prefix still misclassifies. The existing concurrent-request-limit fixtures show Claude Code prefixing 403s with Failed to refresh access token.. For Failed to refresh access token. API Error: 403 You've reached your 5-hour usage limit, the text contains both "token" and "limit", so rule 1 (context overflow) claims it before the new case runs. On this branch it is classified as agent_error.context_overflow.

Suggested shape. I prototyped it on this branch and all existing pkg/taskfailure tests still pass:

var httpForbiddenCodeRe = regexp.MustCompile(`(^|[^0-9])403([^0-9]|$)`)

// isUsageLimit403 is shared by Classify and NormalizeDaemonReason so new and
// old daemons land on the same reason.
func isUsageLimit403(lower string) bool {
	return httpForbiddenCodeRe.MatchString(lower) && strings.Contains(lower, "usage limit")
}

• In Classify, check it right after the concurrentRequestLimitWitness case, before rule 1.
• In NormalizeDaemonReason, right after the concurrent-limit rule, upgrade the same legacy set (context_overflow, provider_auth_or_access, unknown, agent_error) to provider_quota_limit when it matches.

Requiring the 403 keeps the change scoped to the conflict this PR is about. Other "usage limit" wordings stay where main puts them today; for example, a 429 ... tokens-per-minute usage limit message is unaffected.

Tests to add: the access-token-prefixed variant, old-daemon provider_auth_or_access → quota and context_overflow → quota upgrades, and a plain 403 that stays auth.

[drakeo338]

Both points are done with the shared isUsageLimit403 helper; added the access-token-prefixed case to TestClassifyOrderingPriorities and TestNormalizeDaemonReasonUpgradesUsageLimit403 (auth/context_overflow upgrades, plain 403 stays auth).

[multica-eve]

Thanks @drakeo338 for the focused fix and for addressing both review points. The shared 403 usage-limit check now handles the access-token prefix and corrects classifications reported by older daemons, while preserving plain 403 authentication errors and concurrent-request-limit precedence.

The updated code and regression coverage look good. Approved; CI has been authorized to run before merging.

Both requested changes are resolved in adccbc8; the updated implementation has been reviewed and approved.