Document RepositoryRole actor_id values for ruleset bypass_actors — critical security feature, currently undocumented

Localiza la descripción del esquema RepositoryRole actor_id en la definición OpenAPI de este repositorio y revisa cómo están documentados los valores enum o de rol relacionados. Documenta las asignaciones de actor_id confirmadas, incluyendo maintain, write y admin, y valida después que el esquema siga siendo válido.

We have a merge queue with audit rules. Those audit rules are generally working. However, we're pre-packaging rules in an upstream repo that's leveraged by downstream repos. Therefore, those downstream repos need the agency to be able to push through their own changes in case the upstream workflow is broken. So we need to put in place security bypasses, for admin and maintainer, via bypass_actors.

Considering Admin is #5, per the Repository roles page's pre-defined role ordering (Read, Triage, Write, Maintain, Admin), I would assume Read is 1, Triage is 2, Write is 3, Maintain is 4, and Admin is 5.

Much to my surprise, if I had chosen #4, literally anyone with write access to the repo would be able to automatically supersede the audits and push their merge through — the real mapping is maintain: 2, write: 4, admin: 5, not sequential at all.

The only indication of truth for this is a single community PR, added because "there seems to be confusion regarding this" — no GitHub confirmation cited. As Douglas Adams put it: "But the plans were on display…" "On display? I eventually had to go down to the cellar to find them." "That's the display department." "With a flashlight." "Ah, well, the lights had probably gone." "So had the stairs." "But look, you found the notice, didn't you?" "Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'" That's exactly what this is.

This is a critical security feature and it should not be undocumented, and it should not be eligible to be pulled out from under us the way OrganizationAdmin's ID already was — silently invalidated, only caught in #3487. Look at what happened with left-pad in 2016: a single unaffiliated dependency, pulled with no warning, broke everything downstream that had quietly come to rely on it.

Ask: publish the real RepositoryRole actor_id values directly in this repo's schema description for actor_id, so this stops being sourced from third-party, unconfirmed docs for a control this security-sensitive.