[copilot-finds] Bug: InMemoryOrchestrationBackend suspend/resume methods do not update instance status

[github-actions]

Problem

The InMemoryOrchestrationBackend.suspend() and resume() methods queue the appropriate SuspendEvent/ResumeEvent history events but never update instance.status. This causes getOrchestrationState() to return incorrect runtime status:

• After calling suspend(), status remains RUNNING instead of SUSPENDED
• After calling resume(), status remains SUSPENDED instead of RUNNING

Files: packages/durabletask-js/src/testing/in-memory-backend.ts, lines 168–203

Root Cause

In the real DTS sidecar, the suspend/resume RPCs immediately transition the orchestration status. The executor does not produce a COMPLETEORCHESTRATION action for suspend/resume — it only sets an internal _isSuspended flag to buffer/unbuffer events. The in-memory backend relies on processCompleteOrchestrationAction to update status, but since no completion action is generated for suspend/resume, the status was never updated.

Proposed Fix

1. Set instance.status = ORCHESTRATION_STATUS_SUSPENDED in suspend() to match real sidecar behavior
2. Transition instance.status from SUSPENDED back to RUNNING in resume()
3. Call notifyWaiters() from both methods so waitForState() predicates checking for SUSPENDED status are properly triggered

Impact

• Severity: Medium — affects testing accuracy. Tests using the in-memory backend observe incorrect RUNNING status after suspend, which differs from real sidecar behavior.
• Affected scenarios: Any test checking OrchestrationStatus.SUSPENDED via getOrchestrationState() or waitForState() after calling suspend().
• Risk: Low — change is scoped to the test infrastructure (InMemoryOrchestrationBackend), not the production gRPC path.