Document TypeScript SDK workflows under Building #1391

Parent

• TypeScript SDK for mecatl (browser + Node) #761
• Prototype @stacklok/mecatl-sdk TypeScript SDK #821 M4 documentation and examples

Problem

The TypeScript SDK has one public page under Building, but that page currently
combines installation, connection choices, local daemon ownership, browser
deployment, permissions, plans, durable activity, teams, schedules, and callback
tools. It cannot serve as both a first-run guide and the canonical treatment of
every SDK workflow.

Builders need a task-oriented SDK section that explains the common workflows
without duplicating the existing feature, deployment, and protocol documentation.

Scope

Create a dedicated user-docs/building/typescript-sdk/ section. Preserve
user-docs/building/getting-started/typescript-sdk.md and its published URL as the
first-run tutorial.

The section should cover:

• choosing among the transport-neutral, Node/Bun, and generated entry points;
• connecting a Node.js or Bun application to an operator-owned daemon;
• connecting browser code through a same-origin backend-for-frontend;
• owning a private local daemon with spawn() or using query();
• creating sessions and consuming runs, events, results, media, and controls;
• resolving permission asks and the two-run plan-approval lifecycle;
• resuming run or session activity with application-owned cursors; and
• registering local callback tools before session creation.

Keep teams, schedules, permission semantics, and transport contracts in their
existing canonical pages. SDK pages should introduce the SDK operation and link to
those pages for shared behavior.

Information architecture

• Add user-docs/building/typescript-sdk/index.md and _category_.json.
• Convert the existing TypeScript SDK page into a focused tutorial that installs
  the package, connects, creates a session, runs one prompt, verifies the result,
  and links to the next workflow.
• Update user-docs/building/index.md, user-docs/_README.md, and relevant inbound
  links.
• Do not move or rename the existing published quickstart URL.

Source of truth

Verify behavior and examples against:

• sdk/typescript/package.json and its three package exports;
• sdk/typescript/src/index.ts and sdk/typescript/src/node.ts;
• the committed API Extractor reports;
• sdk/typescript/examples/ and the SDK test suites;
• the accepted SDK ADRs and docs/architecture.md; and
• the canonical gRPC, HTTP/SSE, deployment, and feature documentation.

Acceptance criteria

• The existing quickstart has one successful first-run workflow and ends with
  useful next steps.
• A dedicated TypeScript SDK section is present under Building and reachable
  from the Building landing page.
• Node.js, Bun, browser+BFF, local daemon, session/run, permission/plan,
  durable-activity, and callback-tool workflows have clear canonical homes.
• Every code example matches a compiled example under
  sdk/typescript/examples/, or has an equivalent compile-time proof.
• Shared Mecatl behavior is linked rather than duplicated.
• Runtime, registry, package-version, transport, and feature-availability
  claims are verified against the shipped surface.
• task sdk:examples:typecheck, task docs, and task site:build pass.

Out of scope

• Hand-maintaining exhaustive method signatures or option tables. Generated
  method reference is tracked in Autogenerate TypeScript SDK method reference #1392.
• Changing the SDK API or runtime behavior solely to simplify the documentation.
• Moving the gRPC or HTTP/SSE contract reference out of user-docs/reference/.