Add chained invoke to the local runner

[yaythomas]

Closes #436
Closes #735

The local runner supports context.invoke.

In-process

with DurableFunctionTestRunner(handler=place_order) as runner:
    runner.register_durable_function("process-payment", process_payment)
    runner.register_function("lookup-price", lookup_price)
    result = runner.run(input='{"sku": "book-1"}')

register_durable_function registers a durable function; the runner
runs it as a child execution. register_function registers a plain
Lambda function; the runner runs it as one invocation.

Web runner

--function-configs gives the functions a durable function may invoke:
a JSON object mapping each function name to its configuration, in the
shape of the Lambda function configuration, or file://<path> to a
file holding it. A durable function carries a DurableConfig; a plain
function has none.

dex-local-runner start-server --lambda-endpoint http://127.0.0.1:3001 \
    --function-configs file://function-configs.json

{
  "process-payment": {"DurableConfig": {"ExecutionTimeout": 60, "RetentionPeriodInDays": 7}},
  "lookup-price": {}
}

The runner invokes targets at the Lambda endpoint and marks every
handler invocation with the header X-Dex-Handler-Invoke: true, so a
Lambda-compatible endpoint runs the handler once instead of starting an
execution.

Behavior

• Validation, outcomes, payload limits, error codes and history events
  follow the service. A target the runner cannot resolve fails in the
  checkpoint response, so the handler raises without suspending.
• A qualified target (process-payment:prod) resolves to the
  registration under that key, else under the bare name.
• The runner emulates one region, fixed at startup (default
  us-west-2). PUT /lambda-endpoint moves the endpoint only and
  rejects another RegionName. Whether that route should exist is Testing: investigate removing PUT /lambda-endpoint from the web runner #736.
• GetDurableExecution and ListDurableExecutions report the function
  ARN qualified with the executed version, and Version, from the
  execution's own region. A numeric qualifier is the version; anything
  else runs $LATEST.
• A child that completes after a runner restart still completes its
  parent's operation: the link is rebuilt from the stored parent ARN.
• Handler invocations and dispatch run on bounded pools of daemon
  threads. Closing the runner during a blocked Invoke no longer holds
  the process; a result that lands after shutdown is dropped.
• run() takes tenant_id.

Behavior changes

• The in-process Lambda context's tenant_id was the synthetic value
  test-tenant-789. It is now None unless run(tenant_id=...) or the
  chained invoke's TenantId gives one, as in Lambda. A handler that
  read the synthetic value will see None.
• The ChainedInvokeStarted history event omits TenantId, as the
  service's history does.

Testing

Unit and e2e suites at 96% coverage; mypy and ruff clean; the JS
examples conformance suite against the web runner, all six
chained-invoke suites passing. A subprocess test proves the process
exits while an Invoke is blocked.

sam

No sam change is needed to release this. sam gains chained invokes once
it passes a reachable Lambda endpoint, generates the function
configurations from the template, and runs handler invocations directly
when the header is present.

[github-actions]

Codex AI review

Found five actionable issues: two crash-recovery gaps can permanently strand chained invokes, plus shutdown, timeout-isolation, and observer compatibility regressions.

Reviewed commit 016ccb33c00e7b8840da85de747444f9ec131aec. Workflow run

[wangyb-A]

LGTM. The design mirrors the service closely. The threads with Codex are well argued.

One optional follow-up, not blocking: the while self._child_starts_in_flight > 0 loop in Executor.shutdown() has no overall bound. It's fine when the parent lane is healthy, but a lane stuck on a store write would hang shutdown. A total timeout plus a warning log would make that failure visible without changing semantics.