Which cleanup mechanisms apply when a Drupal Ajax request is aborted?

When a browser cancels a Drupal Ajax request, the client-side XMLHttpRequest is aborted and the network connection closes. The PHP process handling that request continues running until it reaches PHP's max_execution_time or an explicit connection_aborted() check. For Ajax callbacks that acquire locks or write temporary data, this gap creates uncertainty about when server-side resources are released.

Drupal core does not expose a dedicated hook or event that fires specifically when an Ajax request is aborted. Although the Batch API and Queue workers include connection_aborted() checks in their loops, standard Ajax callbacks do not. The Symfony HttpKernel does dispatch kernel.terminate after the response is sent, including when the connection is aborted, but it remains unclear whether that event is a safe place for cleanup logic in all environments, particularly behind proxies or load balancers.

Is kernel.terminate a reliable cleanup point after an aborted Ajax request, or should developers rely on periodic connection_aborted() checks inside the callback? How do intermediary network devices affect the accuracy of abort detection in either approach?