Address PR Review

Implement review feedback on the active PR only when it holds up under scrutiny. Do not treat comments as a todo list — evaluate each one against the PR's actual requirements, intended behavior, and codebase reality before changing anything.

Do not reply or resolve threads for fixes you land. Reply on GitHub only when you decide not to implement something (or need clarification).

Critical evaluation (read first)

Review comments are suggestions, not orders. Before touching code, answer:

1. What is this PR trying to accomplish? Read the PR title/description, Linear ticket if present, and the diff. A comment that contradicts the stated goal is a decline, not a fix.
2. Is the comment still valid? Read current code at the cited path — many bot comments are stale after prior commits.
3. Is there a real problem? Distinguish:
   • Real bug / security / correctness gap → fix if in scope
   • Missing validation the API contract already promises → fix
   • Style, refactor, or "nice to have" → usually decline unless project rules require it
   • Bot false positive → decline with reason
   • Out of scope for this PR → decline; note if it should be a follow-up ticket
4. Does the suggested fix match project conventions? Prefer existing patterns in the repo over the reviewer's generic advice.
5. What is the blast radius? Avoid drive-by refactors, new abstractions, or scope creep while "addressing feedback."