Decide where comments belong in code

Review where this code needs comments.

Three lists:

**A. Delete** — comments restating what the code says. `// increment counter` above an increment. These make readers stop trusting the comments that matter.

**B. Add** — places where a reader will ask why. Specifically:
- A choice that looks wrong but is deliberate — *the single highest-value comment there is, because the next person will otherwise "fix" it*
- A workaround for an external bug or limitation, with what it is working around
- A constant whose value came from somewhere — a measurement, a spec, a limit
- Ordering that matters and is not obvious
- A branch whose condition encodes a business rule
- Something intentionally not handled, and why

**C. Fix** — comments that no longer match the code. These are worse than no comment.

For each in B, write the comment. One or two lines, stating the reason, not the mechanism.

Rules:
- *Prefer making code self-explanatory over commenting it.* Where a better name or an extracted function removes the need, say that instead of writing a comment.
- Do not propose a comment on every function. Most do not need one.
- Where the reason is genuinely unknown to me, write the comment as a question for the team rather than inventing a rationale.