fix(agent-policy): grant promoter workflow write for protected transitions

[willgriffin]

Parent: happyvertical/iac#1088

The generation-14 candidate is prepared, but the authority rollout fails before canaries: hv-agent-promoter cannot mint the requested workflows: write token for happyvertical/.github.

Grant the existing app Workflows: Read and write, verify the rollout can mint the authority transition token, then dispatch the revision-10 canary for both arc-happyvertical and arc-anytown. No public/external-fork cutover.

[willgriffin]

{"branch": "codex/63-promoter-workflow-permission", "claimed_at": "2026-07-27T01:40:50.278688Z", "heartbeat_at": "2026-07-27T01:40:50.278717Z", "lease_seconds": 14400, "owner": "willgriffin", "runtime": "codex", "schema": "hv-agent-claim:v1", "session": "codex-63-promoter-workflows-019f9ea2", "worktree": "/Users/will/Work/_trees/github/policy-authority-320"}

[willgriffin]

Clearing the stale `agent: implementation` label — the claim on this issue is expired, not live.

From the claim comment above: `claimed_at` / `heartbeat_at` `2026-07-27T01:40:50Z` with `lease_seconds: 14400`, so the lease lapsed at `2026-07-27T05:40:50Z`. It was never heartbeated, and the branch it names (`codex/63-promoter-workflow-permission`) was never pushed — the ref 404s.

Per the kernel an expired claim is invalid, so the label was advertising an owner that no longer holds one. Leaving it also self-blocks: any PR opened against this issue fails the lifecycle check with issue #63 has agent: implementation without exactly one valid live claim until it is cleared. The claim comment itself is left intact as history.

This issue is still open and re-claimable. One correction to its premise, though: the drift failure it points at is not only a workflows: write gap. AGENT_POLICY_ARTIFACT on this repository returns 404 Not Found, not 403 — the variable is genuinely absent, which is the intended end state after happyvertical/have-config#228 step 4 deleted it fleet-wide. The drift checker should not be reading it at all; that half is tracked in happyvertical/have-config#327.

So whoever picks this up should confirm which permission is actually still needed (the promoter's workflows: write for protected transitions) versus which error is the checker's own defect.