retryWithBackoff: non-retryable intent in github-file-ops-server.ts is unenforced

[qozle]

Summary

github-file-ops-server.ts contains two retryWithBackoff call sites (around lines 373 and 588, both in updateRef) with comments that say:

// For non-403 errors, fail immediately without retry
console.error("Non-retryable error:", updateRefResponse.status);
throw error;

However, throwing from inside the operation lambda does not prevent retryWithBackoff from retrying — the function catches all errors unconditionally. So the "fail immediately" intent is silently ignored and the error is retried up to 3 times (with 5–20s backoff) regardless.

Impact

• 400 Bad Request, 404 Not Found, 422 Unprocessable Entity on git ref updates are retried despite being deterministic failures
• Each deterministic failure wastes ~35 seconds of wall time before the action reports an error
• The misleading comments create a false impression that retry behavior is already controlled at these call sites

Relation to #1081

This is related to #1081 (which addresses WorkflowValidationSkipError retries in token.ts). Once #1081's fix lands, the NonRetryable marker interface (src/utils/errors.ts) will be available to classify errors at these call sites too.

Suggested fix

After #1081 is resolved, create an HttpError class that implements NonRetryable for non-retryable 4xx status codes (400, 401, 403, 404, 422), then throw HttpError from the two updateRef call sites instead of a plain Error. The retryWithBackoff default will automatically skip retries for any NonRetryable error.

Alternatively, pass an explicit shouldRetry option at these call sites that checks the HTTP status.

Files

• src/mcp/github-file-ops-server.ts — two updateRef call sites