docs: remove duplicate multimodal page and normalize em/en-dashes (#6112)

docs/templates/concept_guide_template.mdx

@@ -43,8 +43,8 @@ icon: "lightbulb"
 
 ## Key terms
 
-- **[Term]** – [Short definition]
-- **[Term]** – [Short definition]
+- **[Term]**: [Short definition]
+- **[Term]**: [Short definition]
 
 {/* Optional: delete if not needed */}
 ```mermaid

docs/templates/cookbook_template.mdx

@@ -89,7 +89,7 @@ Expected output (Python): `[describe inline]`  ·  Expected output (TypeScript):
 
 [One sentence on why the result is unacceptable.]
 
-## Fix It – [Solution Name]
+## Fix It: [Solution Name]
 
 [Explain the fix and why it helps.]
 
@@ -115,7 +115,7 @@ Expected output (Python): `[describe inline]`  ·  Expected output (TypeScript):
 
 [Highlight the improvement + remaining gap if any.]
 
-## Build On It – [Second Layer]
+## Build On It: [Second Layer]
 
 [Add another enhancement, e.g., metadata filters, rerankers, batching.]
 

docs/templates/feature_guide_template.mdx

@@ -15,7 +15,7 @@ Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Ad
 
 ## Start → Middle → End Pattern
 
-### 1. **Start – Why this feature exists**
+### 1. **Start: Why this feature exists**
 - Frontmatter stays outcome-driven: `title`, `description`, `icon`, optional `badge` (e.g., “Advanced”).
 - Opening paragraph = two sentences: problem, then payoff. Keep energy high right from the start.
 - Include an `<Info>` block titled “You’ll use this when…” with 3 bullets (user persona, workload, expected benefit).
@@ -24,15 +24,15 @@ Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Ad
 - Optional but encouraged: add a Mermaid diagram right after the intro to show how components connect; delete it if the story is obvious without visuals.
 - Add a `## Configure access` snippet (even if it’s “Confirm your Mem0 API key is already configured”) so contributors never forget to mention the baseline setup.
 
-### 2. **Middle – How it works**
+### 2. **Middle: How it works**
 - Create three predictable sections:
-  1. **Feature anatomy** – Diagram or bullet list of moving parts. Use a table if you need to compare modes (platform vs OSS).
-  2. **Configure it** – Step-by-step enabling instructions with `<CodeGroup>` or JSON/YAML snippets. Follow each code block with a short explanation of why it matters.
-  3. **See it in action** – End-to-end example (often reusing operation snippets). Pair code with `<Info icon="check">` for expected results and `<Tip>` for optimization hints.
+  1. **Feature anatomy**: Diagram or bullet list of moving parts. Use a table if you need to compare modes (platform vs OSS).
+  2. **Configure it**: Step-by-step enabling instructions with `<CodeGroup>` or JSON/YAML snippets. Follow each code block with a short explanation of why it matters.
+  3. **See it in action**: End-to-end example (often reusing operation snippets). Pair code with `<Info icon="check">` for expected results and `<Tip>` for optimization hints.
 - Insert `<Note>` blocks for cross-links (e.g., “Also available via REST endpoint `/v1/...`”).
 - Keep the tone instructive but light. No long manifestos.
 
-### 3. **End – Evaluate and go deeper**
+### 3. **End: Evaluate and go deeper**
 - Add an `## Verify the feature is working` section with bullets (metrics, logs, dashboards).
 - Follow with `## Best practices` or `## Tuning tips` (3–4 bullets max).
 - Close with the standard two-card CTA pair: left card = related concept or architecture page, right card = cookbook/application. Keep the comment reminder to double-check links.