The AJAX requests were failing because of a 403 response returned by WP on the calls to /wp-json/tribe/views/v2/html. After some investigation, I discovered that the problem is an interaction with the protections put in place in #19775, which are responsible for blocking access to REST endpoints on sites that have blog_public values powered by more-privacy-options. Briefly, we filter rest_authentication_errors to check for these custom values of 'blog_public', and to fail or succeed based on the status of the logged-in user. Critically, we do this at the default priority of 10. This leaves us in a sort of race condition with some of WP core's filters on rest_authentication_errors, specifically rest_cookie_check_errors(), which runs at 100. Under normal circumstances, this doesn't matter, because all rest_authentication_errors checks are complete by the time the endpoint's permission_callback is invoked. But in the case of the-events-calendar, they do something weird: https://github.com/cuny-academic-commons/cac/blob/7a5cbb8128152f346c04c9d4f2f4c68546dbb634/wp-content/plugins/the-events-calendar/src/Tribe/Views/V2/Rest_Endpoint.php#L158 In their permission_callback, they call rest_authentication_errors again. This double-call results in improperly cached values being returned in a way that tricks the-events-calendar into thinking that the REST request is coming from a logged-out user (ie, the cookie + nonce auth check has failed rather than not being run yet).
I'm not sure this explains the issue in a 100% clear way, but hopefully it's enough for anyone who runs into this in the future.
The solution is simple: to run our rest_authentication_errors callback later, after core's callbacks: https://github.com/cuny-academic-commons/cac/commit/922f3da683682e95d8534d8177422e89d53ab0ef
This has been deployed on the production site.
