Review PR #337 in software-mansion/argent. Use the `gh` CLI to fetch it.

Before doing anything else, fetch this PR and find out WHO AUTHORED IT: `gh pr view 337 --repo software-mansion/argent --json author,isDraft,headRefName`. Everything below depends on the answer — handle the PR as exactly ONE of the two cases that follow, never both.

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.

▸ CASE A — @testuser authored this PR (it's MINE). Treat it like my own work: fix what you find directly on its branch. Do everything in this case:

Fix every confirmed finding directly on the PR's branch, with the SAME reproduction re-run after each fix to prove it lands.

If a PR turns out perfectly clean — no issues, regressions or bad practices left at ANY level — mark it ready for review and report its number to me. This bar is stricter than the swarm loop's: a pass that stopped because only LOW findings were left is clean enough to stop iterating, but a PR still carrying LOW findings is NOT perfectly clean and does not get marked ready. List every PR you cleared at the end.

For review threads that OTHERS have left on these PRs: address each one, and never mark a thread resolved without first replying "Fixed in <commit_hash>" with the real commit hash.

No AI attribution anywhere in git/GitHub — commits authored as me, no Co-Authored-By, no "Generated with" taglines.

▸ CASE B — someone OTHER than @testuser authored this PR (it's THEIRS). This is strictly look-don't-touch — your only deliverable is the review. Do everything in this case instead:

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.

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.

Do NOT mark this PR ready for review and do NOT change its draft/ready state in any way — it isn't yours to advance; only its author decides that.

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.