Make immediate-cancel task termination test deterministic

[junhyeong9812]

Overview

As discussed in #36965, this is a separate, test-only fix for the flaky SimpleAsyncTaskExecutorTests.taskTerminationTimeoutWithImmediateCancel test (the unrelated failure that turned CI red on that pull request). Production behavior is unchanged.

Problem

The test submits a task and immediately closes the executor, then asserts the future was cancelled. The cancellation flag is set by close() on the calling thread, while it is read at the start of the task in TaskTrackingRunnable.run() on a separate worker thread. There is no ordering guarantee between the two: if the worker thread reaches the cancellation check before close() sets the flag, it passes the check, the trivial task completes normally, and the future is never cancelled, so future.get() returns instead of throwing. Under CI load the worker is more likely to win that race, which is why it fails intermittently.

I reproduced this with a tight loop of the same scenario: roughly 2 to 4 failures per 50,000 iterations locally, which becomes more frequent on a loaded runner.

Fix

Override doExecute to capture the task-tracking wrapper instead of starting a background thread, then run the wrapper on the test thread after close() has set the cancellation flag. The same production cancellation path (checkCancelled to future.cancel(false) to CancellationException) is exercised, but the read and write now happen in program order on a single thread, so the race is gone. With the wrapper never started, activeThreads is empty and the termination wait is skipped, so the test is also faster. The same capture technique is already used by cancelledThrottledTaskReleasesPermit. The deterministic version passes 50,000 of 50,000 iterations.