Our deploy now ends by asking the question a connecting client asks: does the authorization server actually answer, and does it advertise dynamic registration? If not, the deploy fails.

Why this rather than trusting the steps: every step already reported on itself, truthfully, and the product still shipped with its front door shut for two days. A pipeline that says "config pushed" is telling you a command ran, not that the thing you wanted is true.

The specific check matters more than the fact of checking. It looks for the registration endpoint, not a 200 — because the two failure modes are different and only one of them shows up in a status code:

• the server is off → the metadata request 404s, which is loud
• the server is on but registration is disabled → a perfectly healthy document comes back that no self-registering client can use, and the failure lands one hop later, inside somebody else's client, where you will never see it

Rejected: making it a warning. A warning in a CI log is exactly what nobody read for two days.