PullLight found 3 issues

When `vercelToken` is set, `source.type === 'vercel'` and the deployment ID is resolved via the Vercel API — but this entire block is only entered when `config.statusContext` is truthy. If a user supplies `vercel-token` but leaves `status-context` empty (or clears it), the Vercel path is silently skipped and `deploymentId` stays `''`. The guard should be `if (config.statusContext || source.type === 'vercel')` so the Vercel path is reachable independently of `statusContext`.

`assert(response.ok, ...)` throws an `AssertionError` whose message includes the raw `response.status`. If the Vercel API returns a 401/403 (bad token) or 404, the error propagates up and is caught by the outer try/catch in `run.ts`, which logs it and may fail the action — but the Vercel token value itself is never at risk of leaking. However, the `hostname` derived from the user-supplied `deploymentUrl` is embedded in the error message and surfaced in CI logs, which is acceptable. No security issue here, but note that a non-JSON error body is silently ignored; if `response.ok` is false and `response.json()` were called it would throw a parse error instead of the clearer assert message — the current ordering is correct.

`config.vercelTeamId || null` coerces an empty string (the default from `action.yml`) to `null`, which is correct. However `config.vercelTeamId` is typed as `string` (not `string | null`) in `Config`, so this expression produces `string | null` at runtime while the type says `string`. This is a type-safety gap: if `vercelTeamId` is later read elsewhere as `string`, a `null` could slip through. Consider typing `vercelTeamId` as `string | null` in the `Config` interface, or keeping it as `string` and passing it directly (the `if (source.teamId)` guard in `vercel.ts` already handles the empty-string case).