fix(safety): make dependency-safety/gate status clickable via env vars

[j7an]

Summary

Restore the clickable PR-gate-status feature originally attempted in the now-removed PR #71, this time using shell environment variables (${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}) instead of GitHub Actions template-expression syntax (${{ github.server_url }}/...).

Three gh api .../statuses/${HEAD_SHA} calls in dependency-safety.yml gain a -f target_url=... argument. Otherwise no behavior change.

Why this form, not the previous one

The previous form (${{ }} template expressions) caused GitHub Actions' scheduler to abort ci-safety.yml's workflow_call invocation of dependency-safety.yml before any job launched — a 0-job startup_failure with no logs. The dogfood was silently broken from 2026-05-28 05:21 until main was reset to pre-#71 state earlier today.

After a chain of unsuccessful workarounds (renaming the dogfood workflow, API disable/enable, file-touch, name: value change, file rename), a clean diagnostic (the reverted PR #76) localized the breakage to exactly those three target_url expressions. Reverting them restored the dogfood within minutes.

Hypothesis under test in this PR: the scheduler's quirk is specifically about ${{ }} template substitution in run: blocks, not about the presence of target_url itself. GitHub Actions exports GITHUB_SERVER_URL, GITHUB_REPOSITORY, and GITHUB_RUN_ID as standard environment variables — same values, but bypass the template-expression analyzer entirely. If the analyzer was the trip wire, the env-var form should be safe.

Test plan

• CI green on this PR (5/5 standard checks): bats, inline-sync, lint-workflow-call, zizmor, Security workflow.
• Critical: Dependency Safety (ci-safety.yml) check on this PR launches a real safety / scan job and reports success — NOT a 0-job phantom. (If it's a phantom, this PR must be reverted immediately and the env-var hypothesis is falsified.)
• dependency-safety / gate row on this PR's check rollup has a non-empty target URL; clicking it lands on this PR's Dependency Safety workflow run page.
• Deferred to next Dependabot PR after merge: confirm the row stays clickable across the pending → success/failure/error state transitions (the third call site).

If the dogfood breaks

The diagnostic is binary. If ci-safety.yml on this PR phantom-fails again:

1. Revert this PR immediately (one-line revert; the rest of main stays clean).
2. Conclude that target_url presence is the trip wire regardless of substitution form.
3. Accept the unclickable gate as permanent. Update CLAUDE.md / Bootstrapping section with the broader rule: don't add target_url to status API calls from a workflow_call workflow's run: block.

Refs

Investigation thread leading here: PRs #71 (target_url, broke dogfood), #72-#75 (failed workarounds), #76 (diagnostic revert, confirmed cause). All squashed out of main's history via the reset earlier today; PR records remain in GitHub UI as historical reference.