PullLight found 3 issues

When `vercelToken` is set, the `source.type` is `'vercel'` and the outer guard is `if (config.statusContext)`. This means `resolveDeploymentIdFromUrl` is only called when `statusContext` is non-empty. If a user sets `vercel-token` but clears `status-context` (to disable GitHub commit-status resolution), the Vercel path is silently skipped and `deploymentId` stays empty — potentially causing a failure or silent miss. The Vercel path should be gated on `config.vercelToken`, not on `config.statusContext`.

`assert` from `node:assert/strict` throws an `AssertionError` (not a regular `Error`) when the response is not OK. The error message includes only the status code and hostname, but not the response body, making it hard to diagnose Vercel API errors (e.g. invalid token, rate limit). Consider reading the response body and including it in the error message.

The Vercel token (`source.token`) is interpolated directly into the `Authorization` header and will appear in any error/debug logs that dump request headers (e.g. via `assert` failure messages or network interceptors). Consider masking the token in log output. This is a minor secret-exposure risk in CI environments.