docs: backfill TOC + decision trees, fix review findings

- Add ## Contents and ## Decision Tree to all 10 existing pattern files
- Fix embed_as/1 semantics inversion in types.md (:self → :dump)
- Fix fabricated __meta__.changes reference in changesets.md
- Fix default primary key type (:integer → :id) in schemas.md
- Combine @impl subsections into single "Minimal Callback Annotation"

patterns/documentation.md

@@ -2,6 +2,20 @@
 
 Patterns extracted from the Elixir standard library source code.
 
+## Contents
+
+1. [@moduledoc with Structured Sections](#1-moduledoc-with-structured-sections)
+2. [@doc with Sections and Examples](#2-doc-with-sections-and-examples)
+3. [@doc since: Version Annotation](#3-doc-since-version-annotation)
+4. [@doc guard: true Metadata](#4-doc-guard-true-metadata)
+5. [@doc false — Hiding from Documentation](#5-doc-false--hiding-from-documentation)
+6. [@moduledoc false — Hiding Modules](#6-moduledoc-false--hiding-modules)
+7. [Mermaid Diagrams in Documentation](#7-mermaid-diagrams-in-documentation)
+8. [Admonition Blocks in Documentation](#8-admonition-blocks-in-documentation)
+9. [@doc deprecated: Soft Deprecation](#9-doc-deprecated-soft-deprecation)
+10. [Callback Documentation Convention](#10-callback-documentation-convention)
+11. [Documentation with Link References (c: and t: prefixes)](#11-documentation-with-link-references-c-and-t-prefixes)
+
 ---
 
 ## 1. @moduledoc with Structured Sections
@@ -1000,4 +1014,17 @@ Returns `true` if the calling process is the owner of this resource.
 
 **Why:** Link references should aid navigation, not turn documentation into hypertext soup. Link types and callbacks that users might need to look up; don't link primitive types or universally known functions.
 
+## Decision Tree
+
+- If the module is a primary entry point with 4+ public functions → use structured `@moduledoc` with sections (Pattern 1)
+- If a function has non-obvious behavior or edge cases → add `@doc` with sections and `## Examples` doctests (Pattern 2)
+- If adding a new public function to a versioned library → annotate with `@doc since: "X.Y.Z"` (Pattern 3)
+- If the function/macro is valid in guard clauses → add `@doc guard: true` metadata (Pattern 4)
+- If a function must be public for technical reasons but is not user-facing → use `@doc false` (Pattern 5)
+- If an entire module is purely internal implementation → use `@moduledoc false` (Pattern 6)
+- If documenting multi-component architecture (client-server, pipelines) → embed a Mermaid diagram (Pattern 7)
+- If critical information must stand out (security, breaking changes, `use` behavior) → use an admonition block (Pattern 8)
+- If a function still works but a better alternative exists → use `@doc deprecated:` for soft deprecation (Pattern 9)
+- If defining a behaviour callback with multiple return shapes → write comprehensive callback docs with trigger, params, returns, and example (Pattern 10)
+
 <!-- PATTERN_COMPLETE -->