Add deferred findings policy to code review page

Require PR authors to create a GitHub issue for any review
finding deferred past the current PR, and link it in the
review thread before merging. Prevents informal tracking
from dropping items.

code-review.md

@@ -34,6 +34,20 @@ Code review exists to catch defects, share knowledge, and maintain consistency.
 - Ask questions instead of making assumptions. "Is this intentional?" is better than "This is wrong."
 - If a PR is good, say so. A simple "Looks good" is fine.
 
+## Deferred Findings
+
+When a reviewer identifies a finding that won't be addressed in the current PR, the PR author must create a GitHub issue for it before the PR merges. No exceptions -- if it's worth commenting on, it's worth tracking.
+
+### Requirements
+
+- The GitHub issue must reference the PR number and link to the specific review comment.
+- The PR author must reply to the review comment with a link to the created issue, acknowledging the deferral.
+- This applies to all severity levels: bugs, nits, refactors, missing tests, documentation gaps.
+
+### Why
+
+Deferred findings handled informally (retro notes, mental to-do lists, "we'll get to it") fall through the cracks. An issue in the backlog is the minimum bar for accountability.
+
 ## Turnaround
 
 - Aim to review within one business day of being requested