[Miniflare][Workflows] Completed steps leave timeout timers active, exhausting the 10,000-timer quota

Finding: In a single-reporter external report, a local Miniflare Workflow running sequential, immediately successful step.do() calls (ten-minute timeout, retries off) failed after 5,000 completed steps with a QuotaExceededError about 10,000 active timeouts. Versions reported: miniflare 5.20260918.0-alpha with workerd 1.20260918.1, and stable miniflare 4.20260730.0, on macOS 27.0 arm64 with Node 26.9.0 (https://github.com/cloudflare/workers-sdk/issues/15788). Because the Workflow catches the exception, terminal status complete and exit code zero do not mean all steps ran; the reporter says to inspect the output's completed and error fields (issue body). Reported evidence: the reporter says the unmodified alpha and stable builds both stopped at 5,000 of 9,000 steps with the same error. A disposable copy of the alpha, changed only to pass an abort signal to scheduler.wait(timeout), completed 9,000 of 9,000 steps. A separate extended no-op run with the same patch and the override stepLimit: 20000 completed 12,000 of 12,000 steps (issue body). Without that override, the extended run hit a separate 10,000-step limit, not a timer-quota error. Suspected cause (the reporter's own analysis, labeled 'Verified cause' by the reporter; no maintainer confirmation appears in the captured comments): timeoutPromise() in packages/workflows-shared/src/context.ts starts scheduler.wait(timeout) without an abort signal. Completion aborts a controller and calls TimePriorityQueue.remove(), but the reporter says this only updates bookkeeping and does not cancel the native timer. The reporter cites workerd's Scheduler::wait() as clearing the timer only when given a signal, and the timer manager as limiting active timers, not cumulative steps (issue body, with the source links it cites). The patched runs are the reporter's own one-line experiment; the reporter describes it as supporting the diagnosis, not as a fully validated fix. Comment and closure status: a commenter with MEMBER author association thanked the reporter on 2026-09-29 (https://github.com/cloudflare/workers-sdk/issues/15788#issuecomment-5892450215). Separately, an LLM-generated automated triage comment from 2026-09-22 marked the issue actionable and said reproduction was skipped (https://github.com/cloudflare/workers-sdk/issues/15788#issuecomment-5783472349). That comment restates the reporter's claims and is not independent evidence of the cause. The issue page state is CLOSED (last updated 2026-10-07); the closure date and reason are not given. No closure reason, fix commit or released version appears in the captured comments, but the captured thread is head/tail only and may omit middle comments, so a closure reason or fix link could exist there. Closure alone is not a fix, so fix status is UNKNOWN. Limitations: this is external-report evidence only and was not reproduced by KFA. The reporter says the one-line experiment is not a fully validated fix; timeout expiry, retry, pause/resume and restart behavior were untested with it. A similar uncancelled wait in gracePeriodSemaphore.ts is a source-level concern whose contribution was not isolated. Version 5.20260921.0-alpha was inspected at source level only, and no deployed Cloudflare Workflows failure was shown. A related Queue-path issue (#15670, PR #15676) is explicitly not evidence of a Workflow fix. Workaround status is UNKNOWN from the captured sources. Possible check if you see similar behavior: confirm you are running local Miniflare Workflows, compare completed steps against the reported 5,000 and look for the active-timeout error text. This is a diagnostic suggestion, not a verified outcome. Do not assume a patched release exists unless project release notes show one.