Review and clean up access across all 5 MathCAT repositories (follow-up to #851, #848)

This is a governance task, not a code change. Start by reading the CODEOWNERS file referenced in #848 and #851, then check each of the five repos' collaborator and team settings in the daisy organization to compare access. Done means the team-access decisions are agreed, the matching changes are made by an admin, and the protection-rule scope for each repo is recorded in the thread.

While working on #848 (adding more detail to CODEOWNERS), I checked who has access to each of the 5 MathCAT code repositories on GitHub, and found some things that don't match what we'd expect. I'm opening this as its own issue because it has its own action items: some decisions to make and some changes that need an organization owner or repo admin to actually carry out.

Background:

As part of DAISY's current pilot year exploring sustainable governance and maintenance, several MathCAT repos have been moved from @NSoiffer's personal account into the shared daisy organization. Organizing access and team structure supports the goal of sharing maintenance load rather than depending on one person.

A few GitHub terms used below:

• Organization (org): a shared GitHub account for a group, rather than one person — in our case, daisy. MathCAT's repositories and teams exist inside this one organization.
• Organization owner: someone with full control over the whole daisy organization — not just one repo. Owners can invite new people into the organization, create or delete teams, and change access to any repo inside it. This is a small, separate group from repo-level admins (below).
• Repository (repo): one codebase inside the organization. MathCAT has 5 of them.
• Organization member: someone who's been invited into the daisy organization. Being a member doesn't automatically give access to any specific repo — that's granted separately, either to the person directly or through a team.
• Team: a named group of organization members (for example, "MathCAT-Maintainers"). Teams exist at the organization level, and can be given access to one or more repos at once, instead of adding each person to each repo one by one.
• Collaborator: a specific person given access to one repo, either directly or through a team they belong to.
• Access levels, from least to most: read (can view and download, cannot change anything), write (can push code changes and merge approved changes), admin (can additionally change settings, rules, and who else has access to that repo).
• Ruleset: a set of rules GitHub can enforce on a repo, like "every change must go through review before merging."
• CODEOWNERS: a file that says which people or teams should review changes to specific folders.

What I found:

1. Access is granted separately for each repo, not as one shared setting. Most of us have similar access on 4 of the repos: MathCAT, MathCATDemo, MathCATForPython, and MathCATForC. The 5th, MathCATForJS, looks different — several of us only have read access there, even though we have write or higher on the others. If that's intentional, MathCATForJS should probably be left out of any change that sets the same team-wide permissions across all 5 repos.
2. The MathCAT-Translators team has no access to any repo yet. This is an organization-level team, and the CODEOWNERS file already lists it as the expected reviewer for language-related files. But GitHub can only auto-request a team as a reviewer if that team already has at least read access to the repo. Right now it doesn't, so those review requests are probably not happening.
3. The MathCAT-Maintainers team only has read access, even though its name suggests members should be able to review and merge changes day-to-day. Right now, the people who actually can merge have that ability because they were added individually as repo collaborators, not because of this organization-level team.
4. Only the main MathCAT repo has any protection rules turned on, and even those are limited. As #851 already notes, they only stop people from deleting the branch or force-pushing over it — they don't require review before merging yet. The other 4 repos have no protection rules at all. #851's proposal would fix this for MathCAT, but doesn't say whether the same rules should apply to the other 4 repos too.

What each team is for, and what access would let them do

Who can make these changes today:

Suggested next steps:

• Decide if MathCATForJS access should match the other 4 repos, or if there's a reason it's different.

• Once we agree on the team access levels above, have one of the people listed in the table actually turn them on, and decide what to do with people's individual access once the teams cover the same ground.

• Confirm whether team maintainers can bring new people into the organization via team invites, without needing an org owner.

• Decide whether the proposed protection rules in #851 should extend to MathCATDemo, MathCATForPython, MathCATForC, and MathCATForJS, or stay limited to MathCAT for now.

• cc @NSoiffer @SarahMorleyWilkins @MartheGjelstad @aimalz