PullLight found 3 issues

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

`assert` from `node:assert/strict` throws an `AssertionError` whose message is the second argument string. When `response.ok` is false, the response body (which may contain a useful Vercel error message) is never read or surfaced. The error message only includes the HTTP status code, making debugging harder. Consider reading `response.text()` and including it in the thrown error.

The Vercel token (`source.token`) is interpolated directly into the `Authorization` header and will appear in any error messages or logs if the `assert` on line 23 fires (the URL and status are logged, but the header object is part of the fetch call visible in stack traces or debug output). More critically, if `deploymentUrl` is attacker-controlled (e.g. a malicious `environment_url` from a GitHub deployment status), the hostname is sent to `api.vercel.com` but the token is always sent to the real Vercel API — this is safe. However, there is no validation that `deploymentUrl` is actually a Vercel URL before constructing the API call, so an unexpected hostname could be leaked in error messages.