Remove the process-local workflow session registration token

> Please provide us with the following information:
> ---------------------------------------------------------------

### This issue is for a: (mark with an `x`)
```
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
```

### Minimal steps to reproduce
> 1. Inspect `src/azure_functions_agents/workflows/context.py`.
> 2. Observe that `WorkflowSessionContext.token` is generated by `register_workflow_session()` and used only by `unregister_workflow_session()` to avoid an older request deleting a newer entry from the process-local `_registry`.
> 3. Inspect the current production path in `workflows/tools.py` and `runner.py`. Workflow tools receive a request-local `WorkflowSessionContext` constructed directly from the owner slug, session ID, agent name, and Durable client. This context uses `token=""` and does not look up the registry.
> 4. Observe that no production caller under `src/` invokes `register_workflow_session()` or `get_workflow_session()`.

### Any log messages given by the failure
> N/A. This is design debt rather than a runtime failure.

### Expected/desired behavior
> Remove `WorkflowSessionContext.token` and the unused process-local workflow session registry APIs (`register_workflow_session`, `unregister_workflow_session`, and `get_workflow_session`) if compatibility analysis confirms they are not part of a supported public surface.
>
> `WorkflowSessionContext` should represent only data required by workflow operations, such as owner slug, session ID, agent name, and the Durable client. Workflow status, cancellation, and termination must continue to use the Durable workflow instance ID plus owner/session authorization; they must not depend on process-local state.
>
> If the registry must temporarily remain for compatibility, move it behind a private compatibility boundary and rename `token` to `registration_token` so it cannot be mistaken for a persisted workflow credential or cancellation token. Explicitly document that it is worker-local and disappears on restart.

### OS and Version?
> All supported platforms and Azure Functions hosting environments.

### Versions
> Current `main` / per-agent Dynamic Workflows implementation.

### Mention any other details that might be useful

> The token is not an authentication token, Durable workflow token, or persisted session identifier. It is only a generation marker for concurrency-safe cleanup of an in-memory dictionary:
>
> ```python
> _registry: dict[tuple[str, str], WorkflowSessionContext] = {}
> ```
>
> Example of the race it originally guarded against: request A registers token A; request B overwrites the same registry slot with token B; request A then finishes and must not remove request B's context.
>
> The current request-local production design makes that registry unnecessary. Azure worker crashes and scale-out do not require the token: Durable orchestration state is persisted by Azure Storage or Durable Task Scheduler, while cancellation and termination address the persisted orchestration by instance ID.
>
> Suggested acceptance criteria:
>
> - Remove the registry and token from production workflow context, or isolate and clearly name them as compatibility-only behavior.
> - Preserve workflow start, status, list, cancel, and terminate behavior after a worker restart.
> - Preserve owner/session isolation checks based on the workflow instance ID.
> - Update or remove registry-specific tests.
> - Add a restart-oriented test proving cancellation does not depend on process-local state.
> - Update architecture/API documentation if any exported compatibility surface changes.
>
> This may be a breaking change if the registry helpers are intentionally public, so their export and downstream usage should be checked before removal.

> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Start with src/azure_functions_agents/workflows/context.py, then inspect the production paths in workflows/tools.py and runner.py and check whether the registry helpers are exported or used downstream. Review registry-specific tests and verify workflow start, status, list, cancellation, and termination still preserve owner/session isolation after worker restart; update architecture or API documentation if a compatibility surface changes.

Written by the indexing model from the issue text.