deploy-site-task.yml's verify mode has no secret-forwarding path for a token-gated environment check

[ptr727]

Found while working out the deploy-site build/prune/verify split against Blog's real scripts for #925.

The gap

deploy-site-task.yml's hook invocations forward only SITE_BASE_URL (to build and verify) and DEPLOY_SSH_USER/DEPLOY_SSH_HOST (to prune) as plain env: vars, sourced from vars.*. Blog's checks/check-live-urls.sh, which verify mode wraps, needs a PANGOLIN_ACCESS_TOKEN_ID/PANGOLIN_ACCESS_TOKEN secret pair to open its staging environment's auth gate.

Nothing in deploy-site-task.yml forwards a secret into any hook invocation today. DEPLOY_SSH_PRIVATE_KEY is the only secret that crosses the reusable workflow's own on.workflow_call.secrets boundary, and it is consumed directly by the task's own Install deploy key step, never handed to the hook. A composite action does not read the caller's secrets context on its own, the same way it does not read vars on its own, which is why build/prune/verify each get their vars as explicit env: on the invoking step. The same mechanism would need to exist for a secret.

Ask

Decide the shape of a secret handoff for verify mode (or any mode that turns out to need one), and add it to deploy-site-task.yml. Two candidate shapes:

• A named optional secret pair, e.g. SITE_AUTH_TOKEN_ID/SITE_AUTH_TOKEN, declared in on.workflow_call.secrets and forwarded as env: on the verify invocation only, generic enough that any repo whose auth gate takes an id+token header pair can adopt it without a further hub change.
• Or decide that a token-gated live check stays entirely the hook's own problem, and work out some other way for the hook's steps to receive it, since routing it through the task's declared secrets is what every other cross-repository secret in this design already does.

Blog's own deploy-site adoption is tracked against this gap in docs/reusable-workflows.md's Stage 5 Rollout checklist.