fix: treat 403 from self-client as operational error

[stilla]

Problem

A 403 response from the Polar self-client (e.g., polar.portal.list_payment_methods) was raising PolarSelfClientError — a non-retryable client error — causing Sentry alerts as unexpected failures.

Fix

Add 403 to the PolarSelfClientOperationalError condition in _raise_error. A 403 can occur transiently (e.g., during customer session setup race conditions) and should be treated as an operational error, not a programming/client error.

# Before
if error.status_code == 429 or error.status_code >= 500:
    raise PolarSelfClientOperationalError(message) from error

# After
if error.status_code in (403, 429) or error.status_code >= 500:
    raise PolarSelfClientOperationalError(message) from error

Fixes Sentry issue: SERVER-4M0

_{Sent by @Yopi from Operational error fix.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
polar	Ready	Preview, Comment	May 21, 2026 7:40am
polar-sandbox	Ready	Preview, Comment	May 21, 2026 7:40am

[github-actions]

OpenAPI Changes

No changes detected in the OpenAPI schema.

[Yopi]

Since we know the token is valid, the 403s comes from the user not having access

[frankie567]

Don't you fear this will hide real error/mistakes in the future? For example, if we miss a team owner change, we might try to do stuff on behalf of the wrong member?

[github-actions]

Preview Environment
URL: https://polar-preview-vm.taildbff7b.ts.net/pr-11805
API: https://polar-preview-vm.taildbff7b.ts.net/pr-11805/v1/
Logs: backend
SHA: 9f49dc05db1ed176bf7ab96bfd9a2aa8e7ababbd

[Yopi]

Don't you fear this will hide real error/mistakes in the future? For example, if we miss a team owner change, we might try to do stuff on behalf of the wrong member?

Hmm. That's a good point. I was thinking that it would only be when someone tries to access something they don't have access to legitimately. I'd like to get rid of false positives in alerts somehow though