fix(session-flow): retro chain discovery reports no coverage, and --sessions silently drops a comma-joined list

[kyle-sexton]

Reported from a consuming project's plugin audit (session-flow 0.17.20; both findings re-verified
against HEAD 0.17.24).

F2 — parse_transcript.py --sessions silently resolves nothing for a comma-joined list

skills/retro/scripts/parse_transcript.py declares --sessions with nargs="+" and splits on
nothing. Invoked as --sessions <sid1>,<sid2>,<sid3> — the shape a caller reaches for when the ids
were just written into prose — argparse takes the whole comma-joined string as ONE token. It matches
no transcript file, and the run reports 0 with transcript: a result indistinguishable from "these
sessions genuinely have no transcripts."

A session id never contains a comma, so a token carrying one is unambiguously a caller shape, not an
id. Split on it.

F1 — chain discovery is blind to how much it missed

--chain-from walks previous_handoff frontmatter pointers backwards and stops at the first
session that wrote no handoff file. A chain linked by hand-pasted continuation prompts rather than
save-points therefore terminates early — the reported case ran a 10-session chain and got a
retrospective built from 2 sessions, with nothing in the output signalling that the walk had
stopped.

A two-session retro and a genuinely two-session chain are indistinguishable to the reader. The
parser should report what it saw against what exists (the transcripts present for the project are
the denominator the walk cannot see), and the skill should refuse to present a low-coverage chain
retrospective silently.

Not in scope

The same report's F3 (a subagent completion-signal contract in orchestrate) overlaps an audit item
already resolved separately and is excluded here.