Fix Python executemany fallback rowcount aggregation

[Copilot]

The release workflow failed in the Python binding suite because Cursor.executemany() reported rowcount from only the final row when the generic fallback path was used. This broke newly added coverage for all-NULL and Decimal batch inserts that expect aggregate affected rows.

• What changed

  • Updated the fallback executemany execution path in bindings/python/decentdb/__init__.py to accumulate affected rows per executed row instead of reading only the final statement’s affected count.
  • Introduced a small local helper to fetch statement affected rows after each step, then summed into total_affected.
  • Set self.rowcount for non-query fallback execution from the accumulated total.

• Behavioral impact

  • Cursor.rowcount now reflects total rows processed across the entire fallback batch, aligning fallback behavior with fast batch paths and DB-API expectations.

# Before (fallback path): rowcount reflected only the last executed row
cur.executemany("INSERT INTO t VALUES (?, ?, ?)", rows)
assert cur.rowcount == 1  # incorrect for 3-row batch

# After: rowcount reflects total batch effect
cur.executemany("INSERT INTO t VALUES (?, ?, ?)", rows)
assert cur.rowcount == len(rows)  # 3

[Copilot]

Pull request overview

Fixes Python DB-API Cursor.executemany() fallback behavior so Cursor.rowcount reflects the total affected rows across the entire batch (rather than only the last executed row). This aligns fallback execution with the optimized batch paths and typical DB-API expectations, unblocking Python binding suite coverage around batch inserts (e.g., all-NULL and Decimal).

Changes:

• Accumulate affected rows during fallback executemany() by summing ddb_stmt_affected_rows() after each step.
• Set self.rowcount for non-query fallback execution to the aggregated total.