Wire the AI feature triggers and command handlers end to end

Phase 2 landed each AI feature's core logic with tests. What remains is the wiring that connects them to GitHub events — deliberately grouped here because these all touch the same two files (bin/cli.ts and generateUnifiedWorkflow in src/setup.ts) and doing them separately means editing the same trigger block six times.

Command handlers (#1376)

• buddy-bot handle-comment --payload <event.json> CLI entry point
• Handlers routing to existing machinery: review → reviewDiff, rebase → the rebase path, merge → mergeEligiblePullRequests, fix-ci → attemptFix, remember → addLearning, plan → the plan touch
• 👀 on receipt, ✅/❌ on completion (POST /issues/comments/{id}/reactions)
• Collaborator permission lookup (GET /repos/{o}/{r}/collaborators/{user}/permission) feeding CommandActor.canWrite

Automatic review (#1375)

• pull_request: [opened, ready_for_review, synchronize] trigger, gated on ai.review.autoReview
• Honour drafts, ignoreTitleKeywords, ignoreUsernames
• Skip when needsReview(state, headSha) is false

fix-ci (#1381)

• workflow_run: [completed] trigger filtered to failures on buddy-bot PRs
• Provider method to fetch job logs from the Actions API (the classifier already takes log text)
• Green-base check feeding failsOnBase
• Dependency-PR playbook: feed the PR manifest and release notes into the agent task

Issue enrichment (#1383)

• issues: [opened] trigger
• Quick-links comment with action checkboxes
• Wire renderPackageContext to the scanner's dependency list

Finishing touches (#1380)

• Stacked-PR mechanics on the provider (branch off the PR branch, PR targeting its head)
• Verification gate deciding commit vs degrade-to-suggestions
• Consume parseTouchSelections from the review comment's checkboxes

Gates (#1382)

• AI checks: linked-issue assessment, custom natural-language assertions
• Post-merge actions: changelog append, comment linked issues, dashboard refresh
• pull_request: [opened, synchronize, edited] and pull_request: [closed] triggers

Everything above is additive against shapes that already exist and are tested; none of it requires revisiting a design decision.

Implemented in 1256078.

Shipped: handle-comment and fix-ci CLI entries, a shared runReviewForPR used by the CLI, the @buddy-bot review command and the automatic trigger (so all three assemble guidelines, learnings and analyzer findings identically rather than drifting), provider methods for collaborator permission / reactions / run logs / head SHA, command handlers routing to existing machinery, and the workflow triggers plus command, review and fix-ci jobs.

One correction worth flagging. I initially wired automatic review to pull_request_target, which is the conventional way to review fork PRs. That was wrong here: pull_request_target runs with write permissions and repository secrets in scope while the PR's code is checked out, and review runs static analyzers over that tree — it would hand a fork write access to the repository. Switched to pull_request, with a test asserting pull_request_target never appears in the generated workflow. The cost is that fork PRs need a token with more than the default read-only permissions to be reviewed, which is the right trade.

Two smaller decisions: commenter write access is resolved through the collaborator API rather than inferred, and an unreadable permission result denies rather than grants. And a recorded learning is committed on a branch and opened as a PR rather than pushed to the base — it changes how future reviews behave, so it earns the same review a code change gets.

Still open, and honestly out of scope for one pass: stacked-PR mechanics for finishing touches, the AI gate checks (linked-issue assessment, custom assertions), post-merge actions, and the issues: [opened] quick-links comment. These are additive against shapes that exist; I'd rather file them accurately than claim them.