implementation-harness-review-failedlisted

# Review failed / blocked tasks → better-specified follow-ups Review backlog tasks the harness could NOT complete and turn each into a **demonstrably better** follow-up task — never a blind retry of the same spec. Two ways a task lands here, both terminal (the loop never re-selects or re-opens either on its own, so a human review is the only path back to progress): - **`status: "failed"`** — the OWNER overturned a false success via `tracking/manual-fail.json` (its `reason` field is the owner's own words for why the recorded success was wrong). - **`status: "blocked"`** — the LOOP itself gave up: an agent-reported blocker, or `MAX_ATTEMPTS` exhausted at the top model tier (a `worklog/<id>.md` `failed:blocked` marker + `ledgers/*.jsonl` rows). This is a **deliberate, human-invoked review** — nothing in the loop's run path ever calls it. You are the COORDINATOR: you build the worklist and do the final consolidation; you delegate the actual investigate-and-shape work to one sub-agent per task, running concurrently. It **reuses the exact same pending-tasks / consolidation machinery as `implementation-harness-convert-ideas`** (each agent writes only its own `.harness/.pending-tasks/<slug>.json`; `scripts/consolidate-ideas.sh` does the id allocation, spec writing, `TASKS.json` merge, and single commit+push). It **never touches `IDEAS.jsonl`**. Every review also ends with the **original task closed out AND recorded reviewed** — the coordinator (never a per-task agent, which ne