External Events section doesn't mention RaiseEvent fails when no worker is connected

**What content needs to be created or modified?**

Document an operational constraint for workflow external events: RaiseEvent / raise-event fails when no app worker is connected.
Workflow actor types register with placement only while at least one app worker is connected through GetWorkItems. When an app is down, such as during a restart, raising an event can fail with actor type ... not registered even if workflow instance state is durably persisted and resumes once a worker reconnects.

**Describe the solution you'd like**

Add a note explaining this expected behavior and recommended caller handling:
- Worker registration reflects which host currently serves a workflow actor type.
- A RaiseEvent call while no worker is connected may return a not-registered error.
- Callers building restart or recovery automation should retry the request until a worker reconnects.
This prevents failure being mistaken for workflow-state loss rather than a temporary timing race.

**Where should the new material be placed?**

Workflow Features and Concepts: External Events (https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-features-concepts/#external-events)
A cross-reference or related note in Workflow Suspension/Resumption could also be useful.

**The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos**

NA

**Additional context**

Relevant runtime behavior is implemented in pkg/runtime/wfengine/wfengine.go, specifically OnGetWorkItemsConnectionCallback and OnGetWorkItemsDisconnectCallback.
These callbacks register workflow actor types while workers are connected and remove registration after workers disconnect. Durable workflow state remains intact; workflows resume correctly after worker reconnection.

Start with the External Events section in Workflow Features and Concepts, then read pkg/runtime/wfengine/wfengine.go at OnGetWorkItemsConnectionCallback and OnGetWorkItemsDisconnectCallback. Add the operational note and recommended retry guidance, with a related suspension/resumption cross-reference if useful; done means the behavior is clearly documented without implying workflow-state loss.

Written by the indexing model from the issue text.