Vercel CLI deploy returns “Not authorized” while scoped team/project reads succeed

I’m seeing an authorization mismatch with a Preview deployment from the Vercel CLI and would appreciate guidance on the next safe diagnostic step.

Environment

Vercel CLI 62.4.0
Node.js 22.14.0
macOS arm64
Hobby team
Account membership: OWNER, confirmed
Existing CLI authentication scoped to the same team
Local project metadata matches the remote team and project
No environment-token override, explicit token flag, or alternate global configuration

Reproduction

vercel deploy --yes --scope <team-slug> --target preview

The CLI prints that it is deploying the project, then exits with status 1 and:

reason: deploy_failed
message: Not authorized

There is no Uploading message and no deployment URL is returned.

What succeeds with the same authentication and scope

Reading the scoped team: HTTP 200
Reading the scoped project: HTTP 200
Team membership is OWNER and confirmed
whoami succeeds
Project inspection succeeds

The Vercel dashboard shows the current team-scoped CLI authentication as active, not expired or revoked. Its “last active” value updates immediately after the successful scoped GET requests, which supports that the current authentication is actually being used.

Dashboard observations

No corresponding denial appears in Team or Project Activity
No new Deployment is created by the failed attempt
Earlier Preview deployments for the same project succeeded

Failure-stage inference

Based on the CLI behavior, the failure appears to happen during the initial deployment-creation request, before file upload. It may correspond to authorization on the initial POST /v13/deployments, but I did not capture an HTTP status, API error code, or request ID for the failed request, so that endpoint attribution is only an inference.

Question

What could allow the same active, team-scoped CLI authentication to read the team and project as a confirmed OWNER, while denying Preview deployment creation before upload?

Is there a non-destructive diagnostic that can distinguish an endpoint-specific authorization or scope issue without creating new credentials, broadening grants, changing billing, disabling Deployment Protection, or repeatedly retrying the deployment?