Detect duplicate JSON keys in flow files

[sfc-gh-pvillard]

Closes #77.

Summary

• Pre-validation before parsing: both flow files are scanned with a streaming JSON parser that has STRICT_DUPLICATE_DETECTION enabled before any POJO deserialization. A dedicated validateNoDuplicateKeys() method handles this using a separate JsonFactory so the existing parsing configuration is untouched.
• Clear PR comment error: when a duplicate key is found, a [!CAUTION] block is posted with the file path and exact line/column, matching the style of the existing checkstyle violation block.
• Action exits with code 1: the PR check is blocked until the file is fixed, preventing a silently-wrong diff from giving false confidence to reviewers.
• snapshotA catch tightened: the overly broad catch (Exception e) for the "no original flow" case is narrowed to catch (IOException e), so duplicate-key errors in flowA are now reported rather than silently treated as a first-version flow.

Example PR comment on detection

### Executing Snowflake Flow Diff for flow: `submitted-changes/flows/my-flow.json`

> [!CAUTION]
> Flow file `submitted-changes/flows/my-flow.json` contains duplicate JSON keys (this typically indicates a merge conflict that was not fully resolved): Duplicate field 'flowContents'
> Line 37, column 17

Test plan

• All 27 tests pass (mvn test)
• testDuplicateKeyInFlowBThrowsException - getDiff() throws JsonParseException when flowB has a duplicate key
• testDuplicateKeyInFlowAThrowsException - getDiff() throws JsonParseException when flowA has a duplicate key
• testDuplicateKeyReturnsFailureExitCode - run() returns exit code 1 when a duplicate key is present
• testDuplicateKeyOutputContainsCaution - PR comment output contains the CAUTION callout and the duplicate field name

[sfc-gh-dchaffelson]

This is a clean one, Pierre — and a genuinely nasty failure mode to close off. Validating both files up front with a dedicated strict-duplicate parser is the right call: since JsonParseException is an IOException, relying on the deserialization to surface it would have let a duplicate in the before file get swallowed by the "no original flow" handler, so doing the explicit pre-scan before that try/catch is exactly right. The [!CAUTION] block with file + line/column matches the existing style nicely, and I like that it fails the check (exit 1) so a silently-wrong diff can't give false confidence.

Test coverage is spot on — both flowA and flowB directions, the exit code, and the CAUTION output, with a realistic double-flowContents fixture.

Two small non-blocking notes:

1. Heads-up on merge ordering. This, #76, and #66 all touch FlowDiff.java (and #76 also reworks getDiff / executeFlowDiffForOneFlow), so they'll conflict with each other on merge, not just with main. Worth a rebase whichever lands last.
2. Minor cosmetic: the ### Executing ... for flow: header prints the after path even when the duplicate is in the before file. The message body names the right file, so it's low-impact — just noting it.

Nice fix — LGTM.

[sfc-gh-dchaffelson]

Approving — clean fix for a nasty silent-failure mode. Notes in my comment (merge ordering, cosmetic header) are non-blocking.

[sfc-gh-dchaffelson]

Re-approving on the rebased head — duplicate-key detection is intact and the base is now current after the sibling PRs merged. LGTM.