Prototype SDK provided durable entrypoint

[shivam5]

What did you change, and why?

This adds a packaged durable runtime SDK to databricks-mason. The SDK owns the HTTP server and durable run lifecycle; developer code registers framework-specific invocation and recovery hooks.

from databricks_mason.runtime import DurableAgentApplication

app = DurableAgentApplication()


@app.invoke
async def invoke(payload, context):
    ...


@app.recover
async def recover(payload, context):
    ...


app.run()

The SDK exposes:

• POST /invocations
• GET /invocations/{run_id}
• GET /invocations/{run_id}/events?after={cursor}

Equivalent /api/* routes are available for Databricks Apps. The runtime consumes run_id, session_id, background, and stream; the remaining JSON is passed unchanged to the registered hook.

Durability boundary

The runtime now owns:

• persisted input, status, attempts, heartbeats, events, results, and failures;
• foreground, streaming, background, and background-streaming invocation modes;
• stale-attempt discovery and recovery-hook invocation;
• attempt fencing so an older worker cannot commit after a newer attempt takes ownership;
• in-memory storage for local/tests and Lakebase storage for deployment.

The developer or agent framework still owns JSON/native translation, conversation checkpoints, semantic resume behavior, agent/model/tool failures, and idempotency for external side effects.

Mason integration

• Framework-neutral code lives in databricks_mason.runtime.
• LangGraph helpers live in databricks_mason.langgraph.
• The generated LangGraph template imports databricks-mason[runtime] instead of vendoring agent/mason/* or runtime/runtime.py.
• runtime/main.py imports the application and calls app.run().
• The browser chat app remains enabled by default; mason init --disable-chat-app produces the API-only project.
• mason deploy --session <store> binds the managed store's Postgres resource before application startup, preserves unrelated app resources, and injects the runtime endpoint.
• The old cookbooks/durable-entrypoint/* prototype is not part of this PR.

How do you know it works?

• Mason unit tests: 278 passed.
• Fresh default-chat project: 24 passed, 1 skipped.
• Fresh API-only project: 15 passed, 1 skipped.
• ruff check, ruff format --check, and ty check pass.
• uv build succeeds.
• Generated chat JavaScript passes node --check.
• The wheel contains databricks_mason/runtime, databricks_mason/langgraph, and NOTICE, and advertises the runtime optional dependency.

First milestone scope

This milestone covers worker/process loss, OOM/eviction/restart, stale-worker recovery, and client reconnect/event replay. It does not automatically retry agent exceptions or failed model/tool/API calls, detect semantic lack of progress, guarantee checkpoint restorability, deduplicate external side effects, or recover from runtime-store/regional outages.

[shivam5]

Interface comparison set:

• Prototype transport-neutral durable runtime library #475 — transport-neutral library; developer owns the server
• Prototype SDK provided durable entrypoint #476 — AgentCore-style @app.entrypoint; SDK supplies the app
• Prototype generic JSON durable agent server #477 — supplied generic JSON server
• Generalize long-running agent recovery and replay #467 — Responses-specific LongRunningAgentServer

The first three use the same tiny progress agent and the same run/heartbeat/event durability semantics so the developer-facing differences are directly comparable.