fix(ci): visual acceptance rejects trusted capture and custom Repo Owner roles

## Problem

The new visual-acceptance path cannot complete for [#5075](https://github.com/facebook/astryx/pull/5075), despite a completed trusted capture and an authorized repo owner decision.

Two independent failures are visible:

1. The trusted recapture in the PR Comment workflow fails with `trusted capture identity mismatch`. `gate.mjs` records `GITHUB_RUN_ID` / `GITHUB_SHA`; the workflow tries to override those reserved variables with the triggering CI run, but GitHub keeps the current workflow-run identity. `publish-pr-report.mjs` then compares that manifest to the triggering CI id and rejects it.
2. `/accept-visual` rejects the `Repo Owner` custom role because `getCollaboratorPermissionLevel().data.user.permission` reports `write`, while `data.user.permissions.maintain` is `true`. The workflow checks only the legacy string.

## Evidence

- PR Comment failure: https://github.com/facebook/astryx/actions/runs/33044391880
- Acceptance failure: https://github.com/facebook/astryx/actions/runs/33044449876
- Affected PR: https://github.com/facebook/astryx/pull/5075

## Expected

- Trusted recapture should record the triggering CI run/head through non-reserved environment names.
- Authorization should normalize custom-role capabilities (`permissions.maintain` / `permissions.admin`) before deciding whether the actor may accept.

Inspect gate.mjs, publish-pr-report.mjs, and the PR Comment workflow first, tracing how the triggering CI run and head are passed into the trusted-capture manifest. Then trace getCollaboratorPermissionLevel() in the /accept-visual authorization path. Done means trusted recapture accepts the triggering run and custom Repo Owner roles with maintain or admin capabilities can authorize acceptance.

Written by the indexing model from the issue text.