PullLight found 3 issues

When `vercelToken` is set, `source.type === 'vercel'` but the outer guard is still `if (config.statusContext)`. This means that if `statusContext` is empty (deployment-ID resolution disabled), the Vercel path is silently skipped even though a `vercelToken` was provided. The Vercel lookup should not be gated on `statusContext` — it should run whenever `vercelToken` is set, regardless of `statusContext`.

`assert` from `node:assert/strict` throws an `AssertionError` whose message is the raw string passed. When `response.ok` is false, the error message includes the hostname extracted from the caller-supplied `deploymentUrl`. If that URL is attacker-influenced (e.g. a malicious Vercel deployment URL injected via a PR), the hostname leaks into error logs/outputs. More critically, `assert` does not consume the response body, so the underlying TCP connection may not be released promptly. Consider calling `response.text()` or `response.body?.cancel()` before throwing.

The Vercel Bearer token (`source.token`) is sent to a URL constructed from the caller-supplied `deploymentUrl` hostname via `encodeURIComponent`. Although the base URL is hardcoded to `api.vercel.com`, a `deploymentUrl` with a crafted hostname (e.g. containing `%2F` sequences or unusual Unicode that `new URL` normalises differently) could in theory alter the path. More concretely: there is no validation that `deploymentUrl` is actually a Vercel-owned hostname before the token is used. A compromised or spoofed deployment URL could cause the token to be sent in a request that resolves to an unexpected Vercel API path. Add a check that the hostname ends with `.vercel.app` or another known Vercel domain before proceeding.