Sending external event to Completed orchestration succeeds

**Describe the bug**
When sending an external event to an orchestration in the Completed state, all other Durable SDKs fail. In node, the operation succeeds.

**Investigative information**

- Durable Functions extension version: 3.3.0
- durable-functions npm module version: 3.1.0
- Language (JavaScript/TypeScript) and version: TypeScript
- Node.js version:

***If deployed to Azure App Service***

N/A

> If you don't want to share your Function App name or Functions names on GitHub, please be sure to provide your Invocation ID, Timestamp, and Region - we can use this to look up your Function App/Function. Provide an invocation id per Function. See the [Functions Host wiki](https://github.com/Azure/azure-webjobs-sdk-script/wiki/Sharing-Your-Function-App-name-privately) for more details.

**To Reproduce**
Steps to reproduce the behavior:

Function code:
```typescript

// HTTP Trigger to send external event
const SendExternalEvent_HttpStart: HttpHandler = async (request: HttpRequest, context: InvocationContext): Promise => {
const client = df.getClient(context);
try {
let body = await request.json().catch(() => ({}));
let instanceId = body.toString() || request.query.get("instanceId") || request.params["instanceId"];
if (typeof instanceId === "object" && instanceId !== null) {
instanceId = instanceId;
}
await client.raiseEvent(instanceId, "Approval", true);
return {
status: 200,
body: `External event sent to ${instanceId}.`
};
} catch (ex: any) {
return {
status: 400,
body: `${ex.constructor.name}: ${ex.message}`
};
}
};
app.http("SendExternalEvent_HttpStart", {
route: "SendExternalEvent_HttpStart",
extraInputs: [df.input.durableClient()],
methods: ["GET", "POST"],
handler: SendExternalEvent_HttpStart
});
```

Send an external event to an orchestration that has already completed.

> While not required, providing your orchestrator's source code in anonymized form is often very helpful when investigating unexpected orchestrator behavior.

**Expected behavior**
We should get an error like Python's "Instance with ID {0} is gone: either completed or failed""

**Actual behavior**
The operation succeeds

**Screenshots**
N/A

**Known workarounds**
Check the orchestration status manually first - still introduces race conditions

**Additional context**

- Development environment (ex. Visual Studio)
- Links to source
- Additional bindings used
- Function invocation IDs

Start at the durable client raiseEvent entry point used by SendExternalEvent_HttpStart and trace how a completed orchestration is handled. Compare the current behavior with the expected completed-or-failed instance error, then verify that sending an event to a completed instance no longer succeeds.

Written by the indexing model from the issue text.