fix(retry-batch): handle nil COPY context in line-number retry path (#1333)

[dimitri]

Summary

Fixes #1333.

Background

When a batch COPY fails, retry-batch takes one of two paths:

1. No COPY context (FK violations, deferred constraints): parse-copy-error-context returns nil → previously used an O(N) row-by-row loop, now uses bisect-batch (fixed in Slow insert after foreign key error #1424 / batch retry: use binary search when COPY error has no line number #1734).

2. COPY context with line number (format errors, type errors): uses the line-number-guided retry loop.

The Remaining Bug

In path 2, when a sub-batch retry itself fails with an error that has no COPY context (e.g. an FK violation on a column that also had a format error earlier in the same batch), the code did:

(setf next-error (+ current-batch-pos next-error-relative))
;; next-error-relative is nil → (+ pos nil) → type error

This type error was caught by the outer handler in copy-rows-in-batch.lisp as "BUG: failed to retry-batch: ...". The rejected rows were silently lost — %process-bad-row was never called for them.

Fix

In src/pg-copy/copy-retry-batch.lisp, when parse-copy-error-context returns nil for the new sub-batch error, fall back to bisect-batch for the remaining rows and exit the retry loop cleanly:

(if next-error-relative
    (setf condition  next-error-in-batch
          next-error (+ current-batch-pos next-error-relative))
    ;; No COPY line-number context (e.g. FK violation following
    ;; a format error): fall back to binary search for the
    ;; remaining rows and exit.
    (progn
      (incf nb-errors
            (bisect-batch table-name table columns
                          batch current-batch-pos
                          (- (batch-count batch) current-batch-pos)))
      (return-from retry-batch nb-errors)))

Test Coverage

Added test/fk-reject.load — a regression test that:

• Creates a parent table with IDs 1, 2, 3
• Creates a child table with a FK constraint referencing the parent
• Loads a CSV with rows: (1,1) valid, (2,99) bad FK, (3,2) valid
• Verifies that rows (1,1) and (3,2) end up in the target table (via the --regress expected-output comparison), confirming that neither a crash nor silent data loss occurred

Note: the core crash for pure-FK batches ("Invalid index N for SIMPLE-VECTOR N") was already fixed in #1734 by replacing the O(N) loop with bisect-batch. This PR closes the remaining mixed-error-type edge case.