docs: apply Theodore's accuracy feedback

- getting-started: workflow creation is the + button next to Workflows in the
  sidebar (no "New Workflow" button exists); Exa/Linkup no longer need
  user-supplied API keys on hosted Sim (apiKey is hideWhenHosted in the Exa
  block) — step and FAQ updated.
- workflows overview: chat and API are entry points of the Start trigger, not
  separate triggers — the "swap in a chat/API trigger" sentence now matches
  triggers/start's own model.
- variables: names cannot contain periods — the resolver reads everything
  after the first dot as a path into the value (executor/variables/resolvers/
  workflow.ts splits on dots) — constraint now stated where name normalization
  is taught.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: ouiliame

apps/docs/content/docs/en/getting-started/index.mdx

@@ -24,7 +24,7 @@ Build a people research agent in 10 minutes. It takes a name through a chat inte
 
 <Steps>
   <Step title="Create a workflow and add an Agent">
-    Click **New Workflow** and name it "Getting Started". The **Start block** is already on the canvas — it's the entry point that receives your chat input.
+    In the sidebar, click the **+** next to **Workflows** and name the new workflow "Getting Started". The **Start block** is already on the canvas — it's the entry point that receives your chat input.
 
     Drag an **Agent block** onto the canvas and configure its **Messages**:
     - **System**: "You are a people research agent. When given a person's name, use your search tools to find their location, profession, educational background, and other relevant details."
@@ -38,7 +38,7 @@ Build a people research agent in 10 minutes. It takes a name through a chat inte
   </Step>
 
   <Step title="Add search tools">
-    In the Agent block's **Tools** section, add **Exa** and **Linkup**, and provide an API key for each. The agent decides when to call them.
+    In the Agent block's **Tools** section, add **Exa** and **Linkup**. The agent decides when to call them.
 
     <div className="mx-auto w-3/5 overflow-hidden rounded-lg">
       <Video src="getting-started/started-3.mp4" width={700} height={450} />
@@ -98,7 +98,7 @@ Build a people research agent in 10 minutes. It takes a name through a chat inte
 
 <FAQ items={[
   { question: "How long does the getting started tutorial take?", answer: "About 10 minutes. You will have a fully working workflow by the end." },
-  { question: "Do I need API keys to follow this tutorial?", answer: "You need keys for the search tools (Exa and Linkup). For the model, Sim's hosted keys are included with your plan credits, or bring your own provider key. Without search keys you can still build the basic agent." },
+  { question: "Do I need API keys to follow this tutorial?", answer: "No. On hosted Sim, the model and the search tools run on Sim's hosted keys, included with your plan credits. You can bring your own provider keys if you prefer." },
   { question: "Do I need coding experience to complete this tutorial?", answer: "No. The whole tutorial uses the visual builder and the chat panel — no code." },
   { question: "Can I use a different model?", answer: "Yes. The Agent block supports models from OpenAI, Anthropic, Google, Groq, Cerebras, DeepSeek, xAI, and more, plus local models through Ollama if you self-host." },
   { question: "Can I import workflows from other tools?", answer: "Not directly. But you can describe what you want to Mothership in natural language and have it build the workflow for you, which is usually faster than manual recreation." },

apps/docs/content/docs/en/workflows/index.mdx

@@ -21,7 +21,7 @@ Here's a simple one. It takes an incoming customer message, classifies its categ
 
 ### Trigger
 
-A **trigger** is where a workflow begins and what it hands in. Every workflow has exactly one. The [Start](/workflows/triggers/start) trigger takes input directly, which is what you use while building. In production you swap in a [chat](/workflows/triggers/start), [webhook](/workflows/triggers/webhook), [schedule](/workflows/triggers/schedule), or API trigger, and the downstream blocks don't change.
+A **trigger** is where a workflow begins and what it hands in. Every workflow has exactly one. The [Start](/workflows/triggers/start) trigger takes input directly — from the editor while you build, and from an API call or a chat once deployed. For runs that should start on an event or a timer, you swap in a [webhook](/workflows/triggers/webhook) or [schedule](/workflows/triggers/schedule) trigger, and the downstream blocks don't change.
 
 <WorkflowPreview workflow={CLASSIFY_WORKFLOW} height={170} highlightBlock="start" />
 

apps/docs/content/docs/en/workflows/variables.mdx

@@ -29,7 +29,7 @@ Type `<` in any block text field to open the picker and browse everything you ca
 
 Workflow variables are a global store any block can read or update during a run. Open the panel with **⋯ → Variables** in the top-right of the editor. Each variable has a **name**, a **type**, and a **value**.
 
-Reference one anywhere a field accepts input. For an object or array variable, use dot notation to reach a nested value, like `<variable.config.timeout>`. Name matching ignores case and spaces, so a variable named `My Counter` resolves from `<variable.mycounter>`. Consistent names like `camelCase` are still the clearest.
+Reference one anywhere a field accepts input. For an object or array variable, use dot notation to reach a nested value, like `<variable.config.timeout>`. Name matching ignores case and spaces, so a variable named `My Counter` resolves from `<variable.mycounter>` — but a name can't contain a period: everything after the first dot is read as a path into the value, so `<variable.config.timeout>` always means the `timeout` field of `config`, never a variable named `config.timeout`. Consistent names like `camelCase` are the clearest.
 
 ### Types