fix(chain): note forward-referenced git commands; fix M6 prerequisites

- M11: keep `git reset --hard HEAD~1` (needed to trigger the protected-branch
  rejection) but flag it as a later-module, history-rewriting command (Module 12).
- Stop presenting rebase/pull --rebase as a casual step: M8 leads with the
  beginner-safe recreate-remote and footnotes pull --rebase as out-of-scope;
  M26 merge-only; M11 mentions rebase-merge only as out-of-scope awareness.
- M6: add Module 3 to prerequisites and back-reference the branch material it
  first taught (branch/switch/merge on docs).

Closes #33
Closes #34
Closes #35

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

modules/11-collaboration-humans-and-agents/README.md

@@ -103,9 +103,10 @@ correctness *and plausibility* — the skill Module 10 is built around. They app
 or comment. For AI-generated diffs this gate is doing more work than it used to: the code compiles,
 reads cleanly, and is still wrong in a way only review catches.
 
-**6 — Merge is the commitment.** Approved, the PR merges into `main`. Squash, merge-commit, or
-rebase — your team picks one; the effect is the same: the branch's work is now part of the shared
-trunk. Delete the branch after; its job is done and its name lives on in the merge.
+**6 — Merge is the commitment.** Approved, the PR merges into `main`. Hosts offer a couple of merge
+styles — a squash or a merge commit; your team picks one and the effect is the same: the branch's work
+is now part of the shared trunk. (You'll also see a *rebase-merge* option; it rewrites history and is
+out of scope here.) Delete the branch after; its job is done and its name lives on in the merge.
 
 **7 — The issue closes — ideally by itself.** If you linked the PR correctly, merging closes the
 issue automatically. The receipt is written without anyone touching the issue. That's the satisfying
@@ -286,9 +287,13 @@ git switch main
 echo "# direct edit" >> README.md
 git commit -am "try to push straight to main"
 git push                      # expect: remote rejects the push to a protected branch
-git reset --hard HEAD~1       # undo the local commit; we'll do it the right way
+git reset --hard HEAD~1       # undo the local commit; we'll add the feature the right way, via a PR
 ```
 
+(That `git reset --hard HEAD~1` is a sharp, history-rewriting command from a later module — it drops
+your most recent commit *and* its changes. It's safe here only because that commit was a throwaway to
+test the guardrail; its full treatment and its real dangers are **Module 12**.)
+
 If the push went through, protection isn't on — fix that before continuing. Feeling the server say
 *no* is the point: "never commit to `main`" is now a rule, not a resolution.
 
@@ -428,8 +433,9 @@ own branch.
   upstream is ongoing work, and PRs *from* forks are deliberately limited by hosts (for example, they
   often can't access the upstream repo's CI secrets — relevant once you reach Module 14). For repos
   you own, prefer branches; reach for forks only when you genuinely lack push access.
-- **The loop diagram is the happy path.** Real PRs get change requests, need a rebase onto a moved
-  `main`, or hit a merge conflict (Module 6) when two contributors touched the same lines — exactly
+- **The loop diagram is the happy path.** Real PRs get change requests, need updating when `main`
+  moves underneath them, or hit a merge conflict (Module 6) when two contributors touched the same
+  lines — exactly
   the parallel-agent scenario worktrees mitigate but don't eliminate. The stations are fixed; the
   number of trips around them isn't.
 - **Squash-merge collapses authorship.** If your team squashes, the agent's (or your) individual