PullLight found 3 issues

When `vercelToken` is set but `statusContext` is empty, the `source` is built as `{ type: 'vercel', ... }` but the entire ID-resolution block is skipped because of the `if (config.statusContext)` guard on line 151. This means the Vercel token path is silently bypassed whenever `status-context` is cleared/empty, and `deploymentId` stays `''`. The guard should be `if (config.statusContext || config.vercelToken)` so the Vercel path can execute independently of `statusContext`.

`assert(response.ok, ...)` throws an `AssertionError` (not a regular `Error`) when the Vercel API returns a non-2xx status. The error message includes the raw `hostname` derived from the caller-supplied `deploymentUrl`, but it does not include the response body, making it hard to diagnose auth failures (401/403) or rate-limit errors (429). Consider reading `response.text()` and including it in the thrown message.

The Vercel access token (`source.token`) is passed in the `Authorization` header over a network call. If `deploymentUrl` is attacker-controlled (e.g. a malicious `environment_url` returned by the GitHub Deployments API), the token could be sent to an unexpected host. The code correctly constructs the URL against `api.vercel.com`, but the `hostname` extracted from `deploymentUrl` is only used as a path segment — verify that `encodeURIComponent(hostname)` cannot be crafted to escape the path (e.g. via a hostname containing `/` after URL parsing). A hostname with embedded slashes is not valid per RFC but some URL parsers may accept unusual inputs; consider asserting the hostname contains no `/` before use.