PullLight found 3 issues

When `vercelToken` is set, the `source` is of type `'vercel'`, but the outer guard is still `if (config.statusContext)`. This means that if a user supplies `vercel-token` but leaves `status-context` empty (or clears it), the Vercel path is never entered and `deploymentId` stays `''`. The Vercel resolution path should be gated on `config.vercelToken`, not on `config.statusContext`.

`assert(response.ok, ...)` throws an `AssertionError` whose `message` is the string passed. However, for non-2xx responses the body may contain a useful Vercel error message that is silently discarded. More importantly, the response body is never consumed, which can leave the underlying socket in a bad state in some runtimes. Consider reading (and discarding or logging) the body on error before asserting.

The Vercel token (`source.token`) is interpolated directly into the `Authorization` header and will appear in any debug/verbose HTTP logs or error messages that print request headers. There is no sanitisation or masking. In a GitHub Actions context this is particularly risky because `core.setSecret` is never called for `vercelToken`, so the token value could leak into the action's log output if the fetch library or any error handler prints headers.