Workflow UX: conversational agent steps, runtime goto, and state mutation tool

## Summary

When implementing booking/form-style multi-turn workflows, current declarative patterns are powerful but require composing multiple primitives (`InvokeAzureAgent.externalLoop`, `request_info` resume handling, `ConditionGroup`, `SetValue`, `GotoAction`) into a manual state machine.

It would significantly improve workflow authoring if Agent Framework provided first-class support for:

1. **Conversational agent steps** (sticky active node)
2. **Runtime goto** selected by the active agent
3. **Controlled workflow-state mutation tools** available to the active agent

## Concrete booking example

Imagine a flight booking workflow with 3 agent nodes:

1. `destination_agent` — collect destination city
2. `departure_agent` — collect departure time (multi-turn)
3. `booking_agent` — place booking

Expected conversational behavior:

1. User talks with `destination_agent` until destination is clear.
2. Workflow moves to `departure_agent` and stays there while the user and agent exchange multiple turns.
3. During step 2, user says: "Actually, change destination to Shanghai."
4. Current node should be able to:
- update workflow state (clear invalidated departure fields)
- jump back to `destination_agent`
5. After destination is corrected, workflow should return to `departure_agent`, then continue to `booking_agent`.

Today this is possible, but requires pre-wiring all backtracking paths and manual state updates in multiple places.

## Current capabilities and gap

- ✅ `InvokeAzureAgent` + `externalLoop` can pause and continue conversation.
- ✅ `GotoAction` can jump to previous or later nodes.
- ✅ State can be updated through workflow actions (`SetValue`/`SetVariable`) and output mapping.

- ❌ No first-class **conversational step** abstraction (active-step routing semantics are implicit/assembled).
- ❌ No first-class **runtime goto(target)** primitive chosen by agent at run-time.
- ❌ No first-class **state mutation tool** for agent nodes (with path/type/authorization controls).
- ❌ No built-in `goto + invalidate` atomic operation.

## Proposal

### 1) Conversational step primitive

A step/node mode that keeps the workflow paused on that step until completion criteria is met, and routes subsequent user turns to that active step by default.

### 2) Runtime goto primitive

Allow an active step to request transition to a target step at runtime, e.g.:

- `goto(step=\"destination\")`
- optionally `goto(step=\"destination\", invalidate=[\"Local.Booking.DepartureTime\"])`

### 3) Controlled workflow state tool

Provide a built-in tool for agent nodes, with strict safeguards:

- allowlist of writable state paths (e.g. only `Local.Booking.*`)
- type/schema validation
- optional approval hooks and full audit trail
- deny writes to `System.*` and protected internal paths

### 4) Optional slot semantics

Optional declarative slot ownership/dependencies:

- `collects: [\"destination\"]`
- `depends_on: [\"destination\"]`

Then slot revision can trigger automatic dependent invalidation and guided backtracking.

## Why this matters

These patterns are common in production conversational workflows (booking, onboarding, claims, approvals). Native support would reduce boilerplate and lower the risk of incomplete backtracking/state handling.

I’m happy to help refine API shape or contribute a sample/RFC if maintainers agree this direction is valuable.