GitHub Actions Trusted Source returns 302 /sso-api despite matching claims on Hobby Preview

I’m trying to access a protected Preview deployment from GitHub Actions using Trusted Sources on a Hobby project. Vercel Authentication (Standard Protection) remains enabled.

Setup and observed evidence:

A saved GitHub Trusted Sources rule is restricted to one repository, one development branch, and the Preview environment.
The workflow has id-token: write and obtains a short-lived GitHub OIDC token using core.getIDToken().
The request sends the token in x-vercel-trusted-oidc-idp-token.
Selected claims were checked: issuer https://token.actions.githubusercontent.com; repository, ref, and workflow_ref match the intended repository and branch; audience is https://github.com/ (placeholder for the actual owner). The subject uses GitHub’s newer immutable owner/repository ID format; actual IDs are omitted here.
The saved Workflow field was tested first with the workflow filename and then with .github/workflows/.yml. Both returned the same result.
GET returns HTTP 302 to vercel.com/sso-api on both the development-branch alias and the deployment-specific hostname. The expected application response for this GET is HTTP 405.
These were GET-only checks; no application bearer token or database write was involved.

Could you clarify:

Does the GitHub Workflow field require the workflow display name, exact filename, or full .github/workflows/ path? How is it compared with workflow_ref?
Is GitHub’s newer immutable OIDC subject format supported, and which subject/identity claims must match the rule?
What exact audience is expected? Must it match the owner-level GitHub URL, another value, or an explicitly configured audience?
How must the source and target environments match for an automatic Git-linked Preview deployment whose deployment API target is null?
Is there a safe, read-only way to diagnose which Trusted Sources condition failed without exposing a token?

I’d like to resolve the matching failure while keeping Vercel Authentication and the narrowly scoped rule enabled. Private URLs, tokens, and infrastructure identifiers are intentionally omitted.

I’m trying to access a protected Preview deployment from GitHub Actions using Trusted Sources on a Hobby project. Vercel Authentication (Standard Protection) remains enabled.

Setup and observed evidence:

A saved GitHub Trusted Sources rule is restricted to one repository, one development branch, and the Preview environment.
The workflow has id-token: write and obtains a short-lived GitHub OIDC token using core.getIDToken().
The request sends the token in x-vercel-trusted-oidc-idp-token.
Selected claims were checked: issuer https://token.actions.githubusercontent.com; repository, ref, and workflow_ref match the intended repository and branch; audience is https://github.com/ (placeholder for the actual owner). The subject uses GitHub’s newer immutable owner/repository ID format; actual IDs are omitted here.
The saved Workflow field was tested first with the workflow filename and then with .github/workflows/.yml. Both returned the same result.
GET returns HTTP 302 to vercel.com/sso-api on both the development-branch alias and the deployment-specific hostname. The expected application response for this GET is HTTP 405.
These were GET-only checks; no application bearer token or database write was involved.

Could you clarify:

Does the GitHub Workflow field require the workflow display name, exact filename, or full .github/workflows/ path? How is it compared with workflow_ref?
Is GitHub’s newer immutable OIDC subject format supported, and which subject/identity claims must match the rule?
What exact audience is expected? Must it match the owner-level GitHub URL, another value, or an explicitly configured audience?
How must the source and target environments match for an automatic Git-linked Preview deployment whose deployment API target is null?
Is there a safe, read-only way to diagnose which Trusted Sources condition failed without exposing a token?

I’d like to resolve the matching failure while keeping Vercel Authentication and the narrowly scoped rule enabled. Private URLs, tokens, and infrastructure identifiers are intentionally omitted.