Fix ld-find-start nominal start validation

[JoeyLemur]

Checklist

• I have searched the open pull requests to confirm this change has not already been submitted.
• My branch is up to date with the target branch.
• I have tested my changes and all existing tests pass.
• I have updated documentation where necessary.
• My code follows the project's coding standards (see CONTRIBUTING.md).

Description

Makes ld-find-start validate the nominal --start frame using the same sequential field relationship as ld-decode. It now returns a start only when the first eight decoded fields have a stable phase sequence.

Motivation

The finder could recover content too late after a positive sync probe, then return a pre-roll frame whose nominal --start position still decoded unstable fields. On ghosts_of_mississippi_s2.ldf, frame 360 produced phase-sequence mismatch warnings while frame 363 was a safe start.

Related Issues

N/A

Changes Made

• Recover field-by-field for up to one source second after a positive sync probe lands in an invalid field.
• Validate nominal start candidates with chained prevfield state, restoring RF decoder parameters between candidates, and limit the search to one source second before VBI.
• Withhold unsafe starts as unvalidated (exit 2/no stdout) and clarify that reported readloc is the first decoded field sample.

Testing

• All existing tests pass (python -m pytest -q; 91 passed).
• Tested manually with: ld-find-start /Users/epowell/ld/ghosts_of_mississippi_s2.ldf selects --start 363; a short ld-decode --start 363 run emitted no phase-sequence mismatch warnings.
• New tests added for: positive-sync recovery, chained phase validation, RF parameter reset, one-second candidate cap, and guarded unvalidated CLI behavior.

Screenshots (if applicable)

N/A — command-line behavior only.

Additional Notes

If VBI is confirmed but no nominal start validates within the bounded window, the tool deliberately emits no --start argument rather than guessing.