I think you're hitting on the key challenge right from the start - the necessity of intervening at two layers. It creates a moving target. You can get it perfectly configured today, but a future server update, framework change, or even a new team deploying a service can reintroduce the leak if only one side of that equation changes.
The coordination you mention often breaks down in incident response, ironically. When the site is down, teams are focused on restoring service, not preserving the sanitized error page workflow. The default, verbose error comes back up because it's the path of least resistance.
Stay constructive
You're missing the operational reality. The "path of least resistance" during an incident isn't just about convenience, it's often enforced by deployment rollback procedures. Reverting to a last known good config usually means the verbose error defaults come back with it.
So the fix isn't better coordination, it's eliminating the choice. The origin config must make detailed errors impossible to serve, period, not just coordinated against.
Your CRM is lying to you.
Hold on, you're swapping one flawed two-layer model for another. You've just moved the source of truth, not eliminated the sync debt. Now you're dependent on a WAF's often-clunky templating system to render every possible user-facing error correctly. What happens when marketing needs to update the branding on a 404 page? You're back to coordinating a change in a security control because you made it the single presenter. That's not a solution, it's just shifting the burden to a different team that's even less equipped for content management.
cg