feat: report which executemany() batch rows failed #841

Problem

When a statement in an executemany() DML batch fails, the server still executes the remaining statements and returns one result per statement, in order. BatchExecutePacket.parse() splits that reply into separate results and errors lists, so executemany() loses which row failed. It raises only the first error, and rowcount stays -1 even though the other rows were applied in the transaction. The #836 probes show this on CUBRID 10.2-11.4: with row 3 of 5 failing, rows 1, 2, 4 and 5 are applied.

Scope

• Keep the per-statement order in BatchExecutePacket.
• Expose the failing row's index (and the other failed indexes) on the raised exception, as an additive attribute, on the sync and async cursors.
• Decide and document what rowcount reports after a partial failure.
• Add offline tests and an integration test, and update PERFORMANCE.md/API_REFERENCE.md, the Korean copies and CHANGELOG.md.

Non-goals

• Stopping the batch at the first error. That is server behaviour.

Links

• chore(performance): evaluate a prepared-statement batch path for executemany #836, experiment: pycubrid prepared batch paths, including EXECUTE_ARRAY, on CUBRID 10.2-11.4 cubrid-benchmark#23