ci: tap cask PRs are never actually auto-armed — the handoff relies on an org workflow that skips devantler-authored PRs

> 🤖 Generated by the Daily AI Engineer

## Evidence
`cd.yaml`'s `🍺 Prepare Homebrew cask PRs` job marks each tap cask PR ready "so the tap's own automation arms auto-merge and its checks gate the merge" — but nothing ever arms it. The org `enable-auto-merge` required workflow classifies eligibility on the PR **author**, its allowlist covers only named bots (`dependabot[bot]`, `renovate[bot]`, `github-actions[bot]`, `ksail-bot[bot]`, `coderabbitai[bot]`), and GoReleaser authors the tap PRs with `HOMEBREW_GITHUB_API_TOKEN` as `devantler` — so the workflow's `auto-merge` job SKIPs on every cask PR.

Live case: homebrew-tap#1210 (`chore(cask): update ksail to v7.174.2`) — timeline shows `ready_for_review` 12:03 UTC → `merged` 14:41 UTC by `devantler`, with **no `auto_merge_enabled` event**: it sat ~2.6 h until an hourly agent tick hand-merged it. Every ksail/ksail-desktop release repeats this.

World at Ruin had the same gap and fixed it at the source: its CD job arms squash auto-merge itself via GraphQL `enablePullRequestAutoMerge` off the PR node id (world-at-ruin#197, closing world-at-ruin#169) — the same direct-endpoint pattern this job already adopted for `markPullRequestReadyForReview` after the `login`-scope trap (#6134/#6135).

## Audience & impact
brew users wait hours (not minutes) for each release to become installable, and agent capacity is spent hand-merging a fully programmed, check-gated PR class on every release.

## Expected behaviour
After validating and marking a cask PR ready, the `🍺` job also arms squash auto-merge on it (merging directly when the tap's checks are already green), failing LOUD on arming failure — so the tap's required checks alone gate the merge, with no agent in the loop.

## Acceptance criteria
- [ ] The `🍺 Prepare Homebrew cask PRs` job arms auto-merge (GraphQL, off the node id — never `gh pr merge --auto`, which needs the `login` scope the tap token lacks) on each cask PR it marks ready; tolerates already-armed; merges directly on "clean status"; hard-fails otherwise
- [ ] The stale "the tap's own automation arms auto-merge" comment is corrected to describe the actual mechanism
- [ ] `cask-pr-handoff-workflow.test.sh` asserts the arming step (existing never-merge/`--admin`/ordering assertions kept intact)
- [ ] Verified on the next release: the cask PR merges with no agent involvement (an `auto_merge_enabled` timeline event exists, or the CD job's direct merge fired)

Rough size: S–M (one job step + guard-test update + one release-cycle verification).

Start with the `🍺 Prepare Homebrew cask PRs` job in `cd.yaml`, then read `cask-pr-handoff-workflow.test.sh` and the existing `markPullRequestReadyForReview` handling. Verify that each cask PR is armed through GraphQL after validation, failures are surfaced, and the stale handoff comment and guard assertions reflect the mechanism; confirm the next release merges without agent involvement.

Written by the indexing model from the issue text.