Make test_trigger_lifecycle deterministic instead of timing-based - #73397

related: #60754

AI Summary

The test forked the real trigger runner and gave it a single 0.1 s select window to check in before asserting that the trigger was running. On slow or loaded CI hosts (seen on the MySQL core job) the child had not sent its first state sync yet and the assertion failed. The deletion half already polled with a 10 s deadline, which only widens the same race instead of removing it.

Both halves of the triggerer now live in the test process, joined by a small comms bridge that pushes each runner request through the supervisor's real frame decode, request handling and response encode. The test drives the same calls TriggerRunner.arun makes per iteration and waits on the trigger coroutine itself rather than the clock, so the outcome no longer depends on scheduling speed.

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.