ActionPinFile.parse silently ignores unrecognized lines, so a malformed pin file yields bootstrap pins

[russwyte]

ActionPinFile.parse folds over the file's lines and drops anything the Line regex does not match:

text.linesIterator.foreach {
  case Line(key, ref, ver) => …
  case _                   => ()
}

So a .github/zipx/action-pins.yml with a typo'd key (setup-jav:), a wrong separator, or a stray indent level parses "successfully" and every field it failed to read falls back to the pins baked into the release jar. The generated workflow then pins actions the user did not ask for, with no diagnostic anywhere: the file is present and readable, so loadOption returns Some.

The failure mode that matters is a pin the user deliberately downgraded or held back being silently reverted to the jar default on the next zipxWorkflowGenerate.

Worth deciding between two shapes:

• parse returns Either[String, ActionPins] (or an ActionPins plus a list of unparsed lines), and the plugin reports through the existing ZipxPlugin.orFail boundary. Consistent with how every other zipx failure is reported, and it fits the fifth design guardrail.
• parse keeps its total signature but reports unrecognized lines as GitHub Actions annotations / sbt warnings naming the line number, the way raw script fragments are warned today.

The comment-only and blank lines the file legitimately contains have to stay accepted either way, so this is about distinguishing "a line that is not a pin" from "a line that was trying to be a pin".

Pre-existing behaviour, found while auditing throw sites for #56; not a regression from that work.