manta-handle-reviewer-returnlisted

# manta-handle-reviewer-return If the reviewer reassigns an issue back to you (status `todo`, your PR still open in the comment chain), **read `loop_history` FIRST**, before doing anything else. This is how the loop learns — without it, each return starts from zero and repeats the same mistake. ```bash export MULTICA_WORKSPACE_ID=264c89bb-4659-4570-af7b-5f8daaf87985 multica issue metadata get <ISSUE-KEY> --key loop_history --output json ``` Read the history. For each prior attempt, note: - **What you tried** (`approach` field) — do NOT repeat this approach. - **What was weak** (`self_check` field — the criterion that scored lowest). - **The reviewer's actual Block/Question** from each cycle — these are the ground-truth failures, more reliable than your memory of fixing them. If the SAME Block reappeared after you "fixed" it, that's your signal: your fix didn't address the root cause. See "Recurring / phantom Block" below for diagnosis. **Do not start fixing until you've read this.** Then read the reviewer's most recent Multica comment to identify which kind of return. ## Two cases ### "Review found N Block-severity findings" For each `Block`, check the scope suffix: - **`Block (fix-here)`** → fix the code per the Block list in the PR review, push to the same branch, then reassign back to the reviewer. Do not open a new PR. - **`Block (followup-issue)`** → do NOT try to fix it in this PR. The reviewer's PR comment includes a one-paragraph description meant fo