fullsend: allow triage-level users to trigger /fs-review

Problem

The fullsend reusable dispatch (reusable-dispatch.yml) gates all /fs-review and /fs-fix commands behind has_write_permission, which requires admin, maintain, or write repo access. Users with triage permission cannot trigger agent runs — their commands are silently ignored.

This makes sense for /fs-fix (pushes commits), but /fs-review is read-only analysis that posts a review comment. Requiring write access for a read-only operation is overly restrictive.

Context

Discovered on rhdh-plugin-export-overlays#2778 — a contributor with triage permission commented /fs-review multiple times with no effect, while an admin's identical comment triggered the run immediately.

The repo has 13 users at triage level who cannot trigger reviews, vs 84 users at write+ who can.

Proposed fix

Add a min_permission input to reusable-dispatch.yml (defaulting to write for backwards compatibility) that repos can override in their shim workflow:

# .github/workflows/fullsend.yaml
uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0
with:
  min_permission: triage   # allow triage users to trigger /fs-review

Or, lower the permission floor for /fs-review specifically (since it's read-only), while keeping write for /fs-fix.

Workaround

Created the @redhat-developer/rhdh-fullsend team with write permission on repos that use fullsend. Add users who need to trigger /fs-review or /fs-fix but only have triage-level individual access.

This grants push access as a side effect — the upstream fix (per-command permission floors) would avoid that.

Moved from redhat-developer/rhdh-agentic#100

Start with .github/workflows/reusable-dispatch.yml and compare its current permission gate with the proposed min_permission input and per-command alternative. Check the consuming .github/workflows/fullsend.yaml example, then verify that triage users can trigger /fs-review, /fs-fix remains protected, and the default behavior is unchanged.