Safe-settings for peribolos investigation

https://github.com/github/safe-settings is the ideal type of git-ops configuration that would be desirable https://github.com/github/safe-settings#the-settings-file. It would also be able to handle branch protection and enable repo owners to configure access to their repos by giving access to the repo subdir of the `admin` repo.

Setup involved https://github.com/github/safe-settings/blob/main-enterprise/docs/deploy.md deploying the app by:
1. The public hosted version was not available at the time of evaluation so it was deployed using kubectl on GCP https://github.com/github/safe-settings/blob/main-enterprise/docs/deploy.md#deploying-using-kubectl.
2. Then creating a github app https://github.com/settings/apps/new using the deployed app with the correct permissions https://github.com/github/safe-settings/blob/main-enterprise/docs/deploy.md#permissions. Note that the documentation and actual permission options differ. The documentation has outdated names.
3. Create the `admin` repo and provide a settings file.

The org creation and management works much quicker than with peribolos. However, teams didn't seem to be implemented at the time of evaluation https://github.com/github/safe-settings/issues/251 and thus does not bring us to feature parity with peribolos. Another observation is that the project seems to be lead and maintained by one person and there are quite a few things that are lacking for a more robust mature project, such as a roadmap etc.

Start with the linked safe-settings deployment documentation, settings-file documentation, and issue #251. Compare safe-settings with peribolos for organization management, teams, branch protection, and repository access, noting the documented versus available GitHub App permissions. Done should be a documented parity assessment and recommendation.

Written by the indexing model from the issue text.