hoo-verify-outcomelisted

# Verify an outcome (recompute first, read the claim second) Takes an item slug or a path to a record in `outcomes/`. The job is to recompute the number from raw data and only then look at what the record claimed, so the recomputation cannot be steered by the answer. Read-only over the brain except for the run report and the one signal in step 5. Nothing here changes an item's status, edits an outcome record, or touches the claimed numbers. ## 1. Identity, URL, windows - and nothing else `PYTHONPATH="$CLAUDE_PLUGIN_ROOT/lib" python3 -c` into `core.outcomes.parse_outcome(<path>)`, and use ONLY these three from what comes back: - `item` - which item this is - `url` - the page to pull - `windows` - the before and after date ranges the claim was measured over **Do not read `claimed_before`, `claimed_after`, or `claimed_delta` yet, and do not print them.** This is the whole exercise. A number you have already seen is a number you will unconsciously reproduce: the pull gets framed around it, a mismatch gets re-run "to check", and the verification becomes a confirmation. Steps 2 and 3 happen with the claim unread. No `windows` in the record: derive them from `applied_at` (the 28 days after, against the same 28 days before) and say in the report that the windows were derived, not read. No `applied_at` either - stop and report the record as unverifiable, naming the missing key. Do not invent a window. An item slug rather than a path: resolve it to `outcomes/<item-id>.md` in th