docs: claim an issue before working on it, and do not rewrite pushed branches

CLAUDE.md

@@ -105,12 +105,24 @@ substitute for this list: it cannot see steps 3, 4 or 7.
 Work that answers a GitHub issue goes onto its own branch and into a pull
 request that references the issue. Never push it to `main` directly.
 
+- **Check the assignee before you start, then assign yourself.** An assignee is
+  the only signal other people have that the work is taken; without one, two
+  contributors can spend an evening on the same defect. If the issue is already
+  assigned to somebody else, ask before you begin rather than working in
+  parallel with them. Unassign yourself if you stop.
 - Reference the issue in the pull request: `Closes #N` when the change fully
   resolves it, `Refs #N` otherwise.
 - **Never merge a branch and never close a pull request.** Whether the work
   is done, and whether it lands, is the maintainer's call — not something to
   infer from green CI.
 - `main` is protected; a direct push is rejected, and that is intentional.
+- **Never force-push a branch that has been pushed, without being told to.**
+  Amending, rebasing or squashing published commits is the maintainer's call,
+  the same as merging is. `--force-with-lease` only protects against
+  destroying somebody else's commits; it does not grant permission to rewrite
+  history a reviewer may already have fetched, a comment may already cite, or
+  a pull request already lists. Amend freely before the first push; after it,
+  add a commit, or ask.
 
 The repository is public and takes reports from other people, so the trail
 from a report to the change answering it has to stay visible and reviewable.