Fix cancelling the task that awaits an external workflow cancel

[RachelWanggg]

Fixes #1974.

_cancel_external_workflow awaits its pending future directly, so when the task awaiting ExternalWorkflowHandle.cancel() is cancelled after the request is sent (the workflow is cancelled, an asyncio.timeout or asyncio.wait_for deadline expires, or a TaskGroup sibling fails), the future is cancelled too. Core still resolves the request, and _apply_resolve_request_cancel_external_workflow calls set_result or set_exception on the cancelled future, which raises InvalidStateError. Every workflow task after that fails with "invalid state" and the workflow stays RUNNING.

This change returns early from the resolver when the future is cancelled. Nothing is waiting on it by then, and the request was already sent, so the target is still cancelled. That is the same approach #1352 took for workflow.sleep() timers (#782), and matches the TypeScript and .NET SDKs, where a resolution that arrives after the caller stopped waiting is a no-op. A future that is done for any other reason still raises, as the existing comment intends.

Awaiting the future through _shield_await, as the other operations do, also fixes the success case, but when the request then fails (target not found), nothing retrieves the exception and the worker logs "Future exception was never retrieved" at ERROR.

With default settings main fails the workflow task on this path, so no completed history contains it, and a workflow already stuck on it continues once its worker runs this change (a supervisor stuck on a main worker ended CANCELED after switching to this branch). If workflow_failure_exception_types covers InvalidStateError (for example [Exception]), main fails the workflow instead, and replaying or querying that closed workflow with this change raises a nondeterminism error.

Three new tests, with a TrapCancelWorkflow target where there is one:

• test_workflow_cancel_external_stop_waiting: the workflow stops waiting on cancel() right after sending it, as asyncio.timeout(0) would, and the target still gets the cancel
• test_workflow_cancel_external_stop_waiting_target_missing: the same against a workflow ID that does not exist, so Core resolves the request with a failure (skipped on time-skipping V1, whose test server never resolves that request)
• test_workflow_cancel_external_workflow_cancelled: the client cancels the workflow before its first task, so the cancellation arrives in the same activation that sends the request, and the workflow's cleanup is still running when the request resolves

Each one waits for the resolution event in history before letting the workflow finish, then asserts there is no WORKFLOW_TASK_FAILED. All three fail on main at the pytest timeout, with "invalid state" on every workflow task retry, and pass with the fix. Checking only before set_result fails test_workflow_cancel_external_stop_waiting_target_missing.

Validation, run locally on macOS (Apple Silicon) with Python 3.12, against the bridge built with poe build-develop (no Rust changes):

• poe lint: ruff import and format checks clean, pyright 0 errors, mypy no issues in 277 source files, basedpyright 0 errors, pydocstyle clean
• full suite on the first commit, pytest -n 4 --dist=worksteal -o timeout_func_only=false --timeout 180: 1516 passed, 10 skipped
• after splitting the test, pytest tests/worker/test_workflow.py -n 4 --dist=worksteal: 243 passed, 2 skipped, and with --workflow-environment time-skipping-v1: 211 passed, 34 skipped
• pytest tests/worker/test_workflow.py -k test_workflow_cancel_external_ --workflow-environment time-skipping-v2: 3 passed
• the repro script from the issue: on main 1 of 5 runs and 5 of 5 --cancel-first runs left the supervisor RUNNING with "invalid state" task failures, on this branch all 10 ended CANCELED with no task failures

Not run: Python versions other than 3.12, Linux and Windows.

[tconley1428]

These parameters seem to change the test behavior enough that the test becomes somewhat unreadable. They should probably be separate tests.

[RachelWanggg]

Split into three tests in 8d09f71.