Go through each currently-open PR (draft or ready-for-review) authored by @someuser in software-mansion/argent. Use the `gh` CLI to enumerate them.

These PRs are SOMEONE ELSE'S — not your code to change. UNDER NO CIRCUMSTANCES may you commit, push, or otherwise modify their branch: ABSOLUTELY DO NOT touch their branch in any way. Your one and only deliverable is the code review itself — every finding goes into the review, never into a commit or push on their branch.

Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across the review moves in my CLAUDE.md — claims vs code, nearest twin, non-happy paths, inputs, reachability both ways, and what outlives the call — plus the absence pass (a sibling that has it, prose that promises it, symmetry, and the mutation); every HIGH / MEDIUM finding gets a concrete hard reproduction that proves it real. Keep dispatching swarms until ONE pass comes back clean — that single clean pass ends the loop, so do not run a confirmation pass on top of it.

Hold to the bar in my CLAUDE.md throughout: run the review moves and the absence pass, prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work within the sizing limits there, and never report something fixed without re-running the repro to confirm it landed. SCALE THE VERIFICATION EFFORT TO THE SEVERITY, so the expensive proof goes where it pays: a HIGH or MEDIUM finding earns the full treatment — hard reproduction, a real device if the bug needs one, verifier agents, whatever it takes. A LOW finding gets ONE short adversarial check and nothing more: never boot a device and never dispatch a swarm to confirm a LOW, and if a quick read cannot confirm it, drop it. A NITPICK — style preference, phrasing, or a defect with no reachable consequence — is dropped ON SIGHT: do not spend a single verification step establishing whether a nitpick is real.

Leave a formal GitHub review on each PR (POST a pull-request review, not a top-level comment), following the review-comment rules in my CLAUDE.md: one inline per-line comment per finding anchored to the exact line(s), describe the problem and its concrete impact only (never propose the fix), strip every internal severity/category marking from the text, and never leave an LGTM / "no issues" comment. NEVER POST A DUPLICATE FINDING: before writing a single comment, read EVERY comment and review thread already on the PR — mine, other reviewers', earlier review runs', resolved or not. If an existing comment already mentions a bug you found, do NOT leave a second comment about it under any circumstances — reply on that existing thread instead ("Still present as of <commit_hash>", with the PR's actual current head commit hash). One issue = one thread, ever. A limitation the PR description acknowledges is NOT a resolved finding: if the code still produces a wrong result, report it.

Keep dispatching swarms until every PR you go through comes back clean — where CLEAN means a pass that surfaced no HIGH and no MEDIUM finding. A pass whose findings are all LOW (or nitpicks) COUNTS AS CLEAN: post the LOW ones, drop the nitpicks, and stop iterating on that PR. Only a HIGH or a MEDIUM keeps the loop alive.

Do NOT submit an APPROVE or a REQUEST-CHANGES verdict — the final approve / changes-requested call is mine; post every finding as an inline review comment (submit the review with the neutral COMMENT event, never APPROVE or REQUEST-CHANGES). The ONE deliberate exception to the no-LGTM rule: when a PR comes back PERFECTLY clean — no issues, regressions or bad practices left at ANY level after the full sweep, LOW findings included — leave a single friendly top-level comment (not an inline finding) noting you ran the full E2E sweep and it returned completely clean, and thanking them for contributing. That comment must say what you actually ran and went through — the moves you covered, the reproductions you executed — never a bare impression like "looks correct" or "held up throughout". For example: "Ran the full sweep: claims vs code, nearest twin, non-happy paths, inputs, reachability, lifetime, plus mutation across the new branches and constants. Replayed the flow E2E on a booted sim. Returned clean. Thank you for contributing!". This is a SOFT approval: that comment ONLY — it must NEVER carry an APPROVE action or any other review verdict.

Diplomat attribution tag — a REQUIRED exception to the no-attribution rule, for GitHub commentary only: every comment, inline review comment, review body, and review-thread reply you post as part of this task must begin with the exact prefix `\[[Diplomat](https://github.com/latekvo/Diplomat)\]: `, copied character for character — the `\[` and `\]` are literal brackets, only the word Diplomat is a Markdown link (to https://github.com/latekvo/Diplomat), anything after that link is plain text, and a colon and a space close it — followed by the text you would otherwise have written, so it renders as "[Diplomat]: <your text>". This is the ONE sanctioned attribution; it applies to posted comment/review text ONLY and never changes commit messages, commit authorship, or the no-Co-Authored-By / no-"Generated with" git rules, which remain in force.