Add Transaction::getConflictingKeyRanges() helper for reportConflictingKeys

[s2x]

Description

TransactionOptions::setReportConflictingKeys() is implemented, but there is no way to actually read the reported keys other than knowing the special-key-space layout by hand. After a not_committed (1020) error, the conflicting ranges are published under:

\xff\xff/transaction/conflicting_keys/

where each key is <prefix><user key> and the value is 1 for the start of a conflicting range and 0 for its end. Java exposes this through Transaction.getRange(SpecialKeySpace...); Python and Go document the prefix.

What needs to be done

Add to Transaction.php:

/** @return list<array{begin: string, end: string}> */
public function getConflictingKeyRanges(): array

• Requires setReportConflictingKeys() to have been set on the transaction, and must be called after the failing commit() and before reset()/onError().
• Reads the special range, strips the prefix, and pairs 1/0 markers into begin/end ranges.
• Throw a clear exception (not a raw range-read error) if the option was not enabled.

Consider also a lower-level getConflictingKeys(): array<KeyValue> returning the raw special-key rows.

Acceptance Criteria

• getConflictingKeyRanges() returns the ranges that caused a 1020 conflict
• Clear error when setReportConflictingKeys() was not enabled
• Integration test that forces a write conflict between two transactions and asserts the reported range
• docs/error-handling.md updated
• composer lint and composer test clean

[s2x]

Implemented in #99.

What was changed

• Added Transaction::getConflictingKeys(): list<KeyValue> — reads the \xff\xff/transaction/conflicting_keys/ special-key range after a failing commit and returns the raw rows with the prefix stripped from each key.
• Added Transaction::getConflictingKeyRanges(): list<array{begin: string, end: string}> — pairs the "1"/"0" start/end markers into user key-space ranges. A malformed marker stream (nested/unaligned start/end, unknown marker value) throws RuntimeException instead of silently returning wrong ranges.
• Both throw LogicException when setReportConflictingKeys() was not enabled. The option state is tracked in Transaction::setOption(), so TransactionOptions::setReportConflictingKeys() (which routes through it) is covered.
• Integration test tests/Integration/ConflictingKeysTest.php forces a real write conflict between two transactions, asserts the 1020 commit failure and that one reported range covers the conflicting key. composer lint and the full test suites pass.
• docs/error-handling.md gained a "Conflicting Key Ranges" usage section; CHANGELOG.md entry added under Unreleased → Added.

Note: the marker values in the live special key space are ASCII "1"/"0" (0x31/0x30), matching the issue description.