[Fix] Swap canConvert argument order in CdcActionCommonUtils.schemaCompatible

[0dunay0]

What does this PR do?

Fixes a bug in CdcActionCommonUtils.schemaCompatible() where valid type pairings were incorrectly rejected at CDC job startup.

Root Cause

The original code called canConvert(sourceType, paimonType) asking "can the source type be directly written into Paimon?" For a Paimon INT column against a BIGINT source, this returns IGNORE (narrowing not permitted), blocking the job even though Paimon can safely evolve INT -> BIGINT.

Fix

canConvert(old, new) returns one of:

• CONVERT — old can be widened to new (evolution needed but valid)
• IGNORE — old is already broader than new (source fits as-is, no evolution needed)
• EXCEPTION — incompatible type families

A pairing is compatible if either direction produces CONVERT:

ConvertAction sourceToPaimon = canConvert(sourceType, paimonType, mapping);
ConvertAction paimonToSource = canConvert(paimonType, sourceType, mapping);

if (sourceToPaimon != CONVERT && paimonToSource != CONVERT) {
    return false;
}

This covers both valid cases:

1. Source fits in existing Paimon type as-is (sourceToPaimon == CONVERT)
2. Paimon can evolve to accommodate the source (paimonToSource == CONVERT)

Cross-family pairs (e.g. INT vs STRING) return EXCEPTION in both directions so neither check produces CONVERT and they are correctly rejected.

Cases

Paimon	Source	sourceToPaimon	paimonToSource	Result
INT	BIGINT	IGNORE	CONVERT	compatible — Paimon can evolve
STRING	CHAR(10)	CONVERT	IGNORE	compatible — source fits as-is
BIGINT	INT	CONVERT	IGNORE	compatible — source fits as-is
INT	STRING	EXCEPTION	EXCEPTION	incompatible

Verifying this change

Added testSchemaCompatibleTypeWidening to SchemaEvolutionTest covering all four cases above.

Closes #5640