feat(course): build out all 27 modules, capstone, scaffold, and conventions

Scaffold the course repo and author the full curriculum in dependency-chain
order, following the settled build decisions in handoff.md.

- Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5),
  _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config.
- Modules 1-2: reference exemplars (locked for tone/depth/lab style).
- Modules 3-27: full lessons + runnable labs, each following the template,
  respecting the chain, vendor/model-agnostic, with "feel the pain" labs.
- Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22),
  not written from memory; expansion-zone modules carry Verify-before-publish.
- Capstone: the full loop end to end on the running tasks-app example.

Lab code syntax-checked (Python/shell/YAML); every module has the 7 core
template sections.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT

modules/03-version-control-for-words/lab/adr-template.md

@@ -0,0 +1,41 @@
+<!--
+  ADR template — Architecture Decision Record (lightweight).
+
+  An ADR captures ONE decision so the reasoning survives the meeting. Copy this file into your repo
+  (e.g. docs/adr/0001-some-decision.md), number it, and fill in the sections. Keep it short — an ADR
+  that nobody reads because it's long has failed at its only job.
+
+  In the Module 3 lab you hand this template to the AI and ask it to fill it out for a real decision,
+  then review its draft as a diff before merging. Write one sentence per line where you can: it keeps
+  future git diffs surgical instead of reflowing whole paragraphs.
+
+  Delete these HTML comments when you write the real ADR.
+-->
+
+# ADR NNNN — <short decision title>
+
+- **Status:** proposed | accepted | superseded by ADR-XXXX
+- **Date:** YYYY-MM-DD
+- **Deciders:** <who made the call>
+
+## Context
+
+<!-- What's the situation that forces a decision? The problem, the constraints, what's at stake.
+     One short paragraph. State facts, not the conclusion. -->
+
+## Decision
+
+<!-- The choice, stated plainly in one or two sentences. "We will ___." -->
+
+## Alternatives considered
+
+<!-- The options you did NOT pick, and the one-line reason each lost. This is the part that saves a
+     future reader from re-litigating the decision. -->
+
+- **<option>** — <why not>
+- **<option>** — <why not>
+
+## Consequences
+
+<!-- What this decision makes easier, harder, or impossible later. Include the downsides you accepted
+     with open eyes — an ADR with no negative consequences is hiding something. -->

modules/03-version-control-for-words/lab/runbook-template.md

@@ -0,0 +1,52 @@
+<!--
+  Runbook template — the step-by-step for one operational task.
+
+  A runbook is read under pressure, often by someone who is not the person who wrote it and not at
+  their best (it's 3 a.m., something is on fire). Optimize for "follow it exactly, no thinking
+  required." Concrete commands, expected output, and what to do when a step fails.
+
+  In the Module 3 lab (optional variant) you hand this to the AI to draft a runbook, then review the
+  draft as a diff before merging. Write one command/step per line so git diffs stay clean.
+
+  Delete these HTML comments when you write the real runbook.
+-->
+
+# Runbook — <task name>
+
+- **Purpose:** <one sentence: what this runbook gets you out of>
+- **When to run:** <the trigger — the alert, the symptom, the request>
+- **Owner:** <team or role responsible>
+- **Last verified:** YYYY-MM-DD
+
+## Before you start
+
+<!-- Access, tools, or context the operator needs in hand before step 1. -->
+
+- <prerequisite>
+
+## Steps
+
+<!-- Numbered, concrete, copy-pasteable. After a command, say what success looks like so the operator
+     knows whether to continue. -->
+
+1. <action>
+
+   ```bash
+   <command>
+   ```
+
+   Expected: <what you should see>
+
+2. <action>
+
+## Verify
+
+<!-- How to confirm the task actually worked, not just that the commands ran without error. -->
+
+- <check>
+
+## If it goes wrong
+
+<!-- The two or three most likely failure modes and what to do about each. Where to escalate. -->
+
+- **<symptom>** → <what to do>