Unify Server SDK and SWML guides

[hey-august]

Proposal: one canonical guide set, homed in Server SDKs, with SWML as a tab

SWML and the Server SDK overlap nearly 1:1 on use cases, so maintaining two parallel guide trees means duplicated effort, drift, and split SEO for every task. Users search by task ("record a call"), not by tool — there should be one landing page per task.

Recommendation:

1. Make the Server SDKs Guides tab the canonical guide set. Its existing taxonomy (Getting Started, Build AI Agents, Make and Receive Calls, Manage Resources, Deploy) is already the right task-based skeleton, and analytics show it's already the higher-traffic section.
2. Show SWML as a tab within each guide page, alongside Python/TypeScript. SDK is the default tab. This models the real relationship — SWML is the wire format, the SDK is how you produce it — and matches the strategic direction that the SDK is the way to write SWML. If SWML gets further de-emphasized later, we change tab defaults and framing, not information architecture.
3. The SWML product becomes reference-centric: the language spec (methods, expressions, variables — most of its content already), a quickstart, and the few guides that are genuinely SWML-native (e.g., hosting a script directly as a dashboard resource). Its other guides fold into the canonical set with redirects.
4. Not under Platform: that product means dashboard/config/admin. Putting developer call-flow guides there muddies both sections.

Rules to adopt with this:

• Parity is "SDK always, SWML where reasonable" — SDK-only topics (REST, control plane, deploy) simply have no SWML tab, and that's normal.
• Guide pages separate "the call flow logic" (tabs nearly identical) from "run it" (tabs legitimately differ: paste a script vs. run an app).