chore(ci): call the shared claude-review workflow

[jfrench9]

Reduces claude.yml to its triggers plus the permissions grant (54 → 28 lines). The author gate, runner selection, and the claude-code-action / checkout pins now come from RoboFinSystems/robosystems/.github/workflows/claude-review.yml.

Eleven repos carry this file in two shapes that differ only in runner choice, so every claude-code-action pin bump is currently eleven PRs. This is the first repo onto the shared version.

Also picks up the SHA-pinned checkout — this repo was on the mutable actions/checkout@v7 tag.

No behaviour change: the gate and permissions are identical, and select-runner returns ["ubuntu-latest"] without an API call while RUNNER_LABELS is github-hosted.

Smoke test for the cross-repo path: robosystems already runs the shared workflow via a relative path, but this is the first external caller — the @main reference plus secrets: inherit is the untested part. An @claude mention on this PR exercises exactly that.

[jfrench9]

@claude can you review?

[claude]

Claude finished @jfrench9's task in 1m 26s —— View job

---

Reviewing PR #206

• Gather context (diff, repo CLAUDE.md, shared workflow reference)
• Review .github/workflows/claude.yml changes
• Verify no behavior change (gate, permissions, runner selection)
• Post review feedback

---

Review

The diff itself is clean and does what the description says.

Correct / verified from the diff alone:

• Trigger block (issue_comment, pull_request_review_comment, issues, pull_request_review) is byte-for-byte unchanged, so nothing about when the workflow fires is affected.
• permissions: on the caller job is unchanged in substance (still contents: read, pull-requests: read, issues: read, actions: read, id-token: write — just reordered). Keeping this block on the caller is required: a called reusable workflow's GITHUB_TOKEN is capped by the caller's grant, so this couldn't just move to the callee-only.
• runs-on, timeout-minutes, and steps are correctly dropped — a job with uses: can't declare runs-on/steps itself, that's exactly the point of delegating to the reusable workflow.
• .github/workflows/claude.yml:19-20 comment accurately describes the permissions-inheritance mechanics.

Worth flagging (not blocking):

1. .github/workflows/claude.yml:27 pins the callee with @main — a mutable ref. This is a deliberate tradeoff called out in the PR description (one pin-bump PR instead of eleven), but it's a slight tension with the SHA-pinning hardening this repo just did for third-party actions in chore(ci): SHA-pin third-party actions, add uv Dependabot coverage #205: a change to RoboFinSystems/robosystems's claude-review.yml now takes effect here with zero review on this repo's side. Since robosystems is same-org/trusted and this is presumably the intended tradeoff, I wouldn't block on it — but if the shared workflow repo ever starts tagging releases (e.g. @v1), pinning to a tag would give a middle ground (still one bump for the tag move, but an explicit, reviewable step per consumer).
2. I don't have network/repo access in this session to fetch RoboFinSystems/robosystems/.github/workflows/claude-review.yml, so I can't independently confirm the author gate and select-runner logic there actually match what was removed here (the PR body's claim of "no behaviour change"). That said, this comment resolving via @claude at all is itself the smoke test the PR description calls for — since you're reading this, the @main reusable-workflow call + secrets: inherit path across repos is confirmed working end-to-end.

No other issues found. Scope is tight (single file, triggers/permissions only), consistent with the stated goal.