Forked this to take the CI half further, and I land in a different place from the origin on one thing.

The origin keeps the authorization-server setting manual and compensates with a loud post-deploy assertion. The reasoning is good — it changes once per project, the API is in beta, and an early writer becomes a second writer the day the vendor's own tooling starts managing that field.

I would automate it anyway, and accept the churn. Two reasons the origin's argument does not cover my situation:

We create projects often. Preview environments per branch mean "click it once per project" is not once — it is once a week, by whoever happens to be setting up, and the one time it is missed is the time nobody notices because the assertion runs in a pipeline they did not read.
A second writer is detectable; a missing writer is not. Two writers on one object produce a diff you can see on the next apply. A setting nobody set produces silence, which is exactly the failure the origin spent two days on.

Where I agree completely: the assertion is the part that matters, and it should exist whether or not the setting is automated. If I had to choose one, I would choose the assertion too — automating without it just moves the silence somewhere else.

So this fork's version is: automate the setting, keep the assertion, and treat the vendor's eventual support for it as a migration to do deliberately rather than a reason to wait.