claude.implement prompt: unresolved PR review comments are work items (evaluate → reply or fix)

[gingur-bot]

actions/claude.implement/prompt.md drives implement turns on claude-task issues; work lives on branch claude/task-<n> with a draft PR. When a PR review is submitted (by a human reviewer or the claude.review agent — the intake is author-agnostic), the external event layer (gingur/hooks, the agent flow's event brain — see #75, v4 operator comment) re-assigns the bot to task issue #n, starting a follow-up implement turn. But the prompt's state-load today reads only task-issue comments, so a review-triggered turn would find "nothing new". Teach the prompt to sweep PR review feedback as part of its normal reconciliation — the trigger's origin doesn't matter; every turn sweeps everything outstanding.

Edits to actions/claude.implement/prompt.md:

• State-load (step 1): when a PR exists for the work branch, fetch review state in the same bash invocation: reviews (gh api repos/<owner>/<repo>/pulls/<pr>/reviews) and review threads with resolution state via GraphQL (pullRequest.reviewThreads → isResolved, comments { author { login }, body, path, line, databaseId }) — REST does not expose isResolved; include the working query in the prompt.
• Work-item definition: an unresolved review thread whose last comment is not the bot's. Newer operator comments on the task issue and unaddressed review threads are swept together — one turn addresses everything outstanding (stateless reconciliation; N triggers collapsing into one turn is correct).
• Evaluate, don't blindly fix: for each work-item thread, judge the comment first — the reviewer may be wrong. Then either (a) change the code and reply to the thread ("fixed in <sha>" — gh api repos/<owner>/<repo>/pulls/<pr>/comments -F in_reply_to=<databaseId> -f body=…), or (b) decline in a thread reply with concrete technical reasoning. Every work-item thread gets exactly one of the two — none ignored silently.
• Limits: never resolve threads (resolution belongs to the reviewer/operator), never dismiss reviews. When operator instructions and reviewer comments conflict, the operator wins.
• Summary comment on the task issue: per-thread disposition (fixed / declined + why), plus what was pushed. Follow-up commits go to the same branch (existing convention; never force-push).
• Keep the additions compact and inside the existing reconcile-then-act structure (extend step 1 and the follow-up-turn branch; don't add a parallel decision tree).

Acceptance criteria:

• Prompt contains: the GraphQL thread-fetch recipe, the work-item definition, the evaluate-then-reply-or-fix rule with the reply mechanics, the never-resolve/never-dismiss limits, the operator-outranks-reviewer rule, and the per-thread disposition summary requirement.
• No YAML or README changes in this task.