[SandeepDave2]

Fix:
Extreme split-key values could overflow range calculations, while fractional keys could be incorrectly accepted, causing rows to be skipped.
Reject overflowing bounds and retain wide arithmetic until final range endpoints are calculated. Restrict splitting to native integer types.
NUMERIC/DECIMAL and floating-point keys fall back to a single connection, including whole-valued NUMERIC keys.
Updated the README and add regression tests following the existing pattern.

Addresses VTA-118933

Verification:
Manually tested in fenced mode on Vertica 26.4.0 with PostgreSQL 15:

• Extreme BIGINT loads preserve all 7 rows, with range splitting confirmed.
• Oversized NUMERIC, fractional NUMERIC and FLOAT loads preserve all values.
• Whole-valued NUMERIC loads preserve all 5 rows, with fallback confirmed.
• Normal integer-key loads and rowset controls continue to pass.
• Comparisons verify complete values, duplicates and NULL handling.

[mkottakota1]

Reviewed all changed files. The range-splitting changes address overflow and fractional-key row loss, and the per-parser column mapping prevents state from leaking between loads. The regression tests cover the main failure cases, and the PR’s build checks are passing. One non-blocking coverage suggestion: explicitly assert that whole-valued DECIMAL keys fall back to a single connection.

[SandeepDave2]

Reviewed all changed files. The range-splitting changes address overflow and fractional-key row loss, and the per-parser column mapping prevents state from leaking between loads. The regression tests cover the main failure cases, and the PR’s build checks are passing. One non-blocking coverage suggestion: explicitly assert that whole-valued DECIMAL keys fall back to a single connection.

I’ll add an explicit assertion that whole-valued DECIMAL keys fall back to a single connection in a follow-up PR.