pm validate reports ok:true / checked_items:0 for a structurally-unparseable item instead of failing — unusable as a post-merge integrity gate #607

Summary

pm validate is the natural merge-safety gate for a multi-agent workflow — run it after resolving a merge to confirm the workspace is intact. But when an item .toon is structurally unparseable (e.g. a count-prefix header like notes[2] that disagrees with the number of data lines — the exact corruption a botched concurrent-append merge produces, see #606), pm validate reports ok: true and checked_items: 0. It silently skips the broken item instead of failing on it. Meanwhile pm get <id> on that same item hard-errors with exit 1 "TOON item document is not valid TOON". So the item is provably unreadable, yet the workspace-integrity command gives a clean bill of health.

Environment

• pm-cli 2026.7.18

Reproduction

W=$(mktemp -d); P="$W/.agents/pm"
pm init mt --pm-path "$P" >/dev/null
ID=$(pm create issue T --pm-path "$P" --json | jq -r .item.id)
pm note "$ID" seed --pm-path "$P" --author seed >/dev/null
TOON=$(find "$W" -name "$ID.toon")

# Simulate a botched merge resolution: header says notes[2] but there are 3 note lines
#   (union kept, count left stale — the realistic near-miss of a concurrent-append merge)
# ...edit $TOON so header is notes[2] with 3 data lines...

pm get "$ID" --pm-path "$P" --json ; echo "get exit=$?"
#   -> {"code":"invalid_argument_value","detail":"...not valid TOON"}  exit=1   (item unreadable)

pm validate --pm-path "$P"
#   -> ok: true
#      has_warnings: true
#      checks: - name: metadata  status: ok  details: checked_items: 0
#   VALIDATE EXIT = 0

Impact

• pm validate cannot be trusted as a post-merge integrity gate — the one thing it must catch (an item that no longer parses) is exactly what it skips.
• checked_items: 0 reads as "nothing to check / all good" when it actually means "I could not parse the item and moved on". An agent scripting pm validate && git commit will commit a corrupt workspace with exit 0.

Expected

A .toon file that fails to parse should make pm validate fail (non-zero exit, ok: false) and name the offending file — or at minimum surface a distinct unparseable_items count separate from checked_items, so checked_items: 0 never coexists with an on-disk item that exists but can't be read. A count/data-line mismatch specifically should be reported as a repairable finding (offer to recompute the header), not silently dropped.

Relationship to other issues

Complements #606 (the count-prefix format that produces the corruption) and #603/#604 (validate/verify give false-green after lossy merges). This one is narrower and general: any unparseable item is invisible to pm validate, independent of how it got that way.