fix(ci): allow bot responses on fork PR inline review comments (#1421)

## Summary

- Remove the fork filter (`head.repo.full_name == github.repository`)
from the `pull_request_review_comment` trigger in `claude-mention.yaml`
- The filter was added in cd16545 based on the assumption that secrets
aren't available for fork PRs — but that restriction only applies to
`pull_request` events, not `pull_request_review_comment` (which runs on
the base repo and has full secret access)
- The `issue_comment` path already works on fork PRs, confirming this

Supersedes #1420 (workaround that only posted a redirect notice).

## Test plan

- [ ] Verify CI passes (workflow-only change, no code)
- [ ] Test by posting an inline review comment mentioning
`@worktrunk-bot` on a fork PR

Closes #1419

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Author: worktrunk-bot

.github/CLAUDE.md

@@ -96,7 +96,7 @@ All workflows pass BOT_TOKEN to both paths.
 |----------|-------------------|-------------------|-------------|
 | **review** | PR diff content (initial review), review body on bot PRs (respond) | Full (any external PR) / Medium (anyone who can review bot PRs) | Fixed prompt, merge restriction |
 | **triage** | Issue body | Partial (structured skill) | Fixed prompt, merge restriction, environment protection |
-| **mention** | Comment body on any issue/PR, inline/conversation comments on bot-engaged PRs | Full | Fixed prompt, merge restriction, fork check on inline review comments, non-mention triggers verified against bot engagement via API |
+| **mention** | Comment body on any issue/PR, inline/conversation comments on bot-engaged PRs | Full | Fixed prompt, merge restriction, non-mention triggers verified against bot engagement via API |
 | **ci-fix** | Failed CI/docs-build logs | Minimal (must break CI or docs build on main) | Fixed prompt, automatic trigger |
 | **renovate** | None | None | Fixed prompt, scheduled trigger |
 
@@ -141,7 +141,7 @@ The mention workflow runs for any user who includes `@worktrunk-bot` — the mer
 - `worktrunk-bot`'s own comments or reviews (loop prevention)
 - Empty approvals on `worktrunk-bot` PRs (approved with no body)
 - Comments on issues or PRs where `worktrunk-bot` hasn't engaged and no `@worktrunk-bot` mention
-- Inline review comments on fork PRs (secrets unavailable)
+- Inline review comments from `worktrunk-bot` itself (loop prevention)
 - Draft PRs
 
 **Routing:** Formal reviews (`pull_request_review`) → `claude-review`. Inline comments (`pull_request_review_comment`) and conversation comments (`issue_comment`) → `claude-mention`.

.github/workflows/claude-mention.yaml

@@ -29,16 +29,18 @@ jobs:
     # and where to look; Claude reads the full context itself via gh/skills.
     #
     # Note: secrets cannot be used in job-level `if:` (actions/runner#520) —
-    # doing so causes GitHub to fail the workflow on push validation. For review
-    # comments on fork PRs (which don't receive secrets), we detect forks via
-    # github.event context instead. Use a Conversation tab comment for fork PRs.
+    # doing so causes GitHub to fail the workflow on push validation.
+    #
+    # Unlike `pull_request`, the `pull_request_review_comment` event runs on
+    # the base repo and has access to secrets even for fork PRs — no fork
+    # filter needed. (The `issue_comment` path already works on fork PRs
+    # for the same reason.)
     if: |
       (github.event_name == 'issues' &&
         contains(github.event.issue.body, '@worktrunk-bot')) ||
       (github.event_name == 'issue_comment' &&
         github.event.comment.user.login != 'worktrunk-bot') ||
       (github.event_name == 'pull_request_review_comment' &&
-        github.event.pull_request.head.repo.full_name == github.repository &&
         github.event.comment.user.login != 'worktrunk-bot')
     # Job-level concurrency (not workflow-level) so that runs skipped by the
     # `if:` above don't enter the concurrency group. Workflow-level concurrency