feat(bindings): expose transaction and maintenance parity through Python Node and CLI #755

Problem

Durability and transaction guarantees are only public if Python, Node, and CLI callers can use the Rust-owned lifecycle without wrapper-side buffering, filesystem manipulation, or divergent error semantics.

Objective

Expose thin parity surfaces for transactions, recovery evidence, retention/GC, and compaction.

Requirements

• Bind Rust transaction begin/stage/validate/commit/rollback/status with idiomatic scoped cleanup.
• Expose safe recovery/open evidence and maintenance preview/run/status.
• Expose compaction controls and progress without allowing arbitrary path deletion.
• Preserve exact 64-bit counts/sizes in Node.
• Map typed Rust errors, committed/unknown outcomes, cancellation, and conflicts consistently.
• Ensure wrapper object finalization never silently commits.
• Add CLI commands suitable for scripts with stable machine-readable output.
• Keep graph values, queries, credentials, and host paths out of diagnostics.
• Document mode/isolation behavior and examples identically across surfaces.

Acceptance Criteria

• Python, Node, and CLI invoke the same Rust facade operations.
• Mixed transaction commit and explicit rollback have parity tests in all consumers.
• Node progress/count fields remain lossless above the safe integer range.
• Dropped wrapper handles roll back or release safely and never commit.
• Maintenance preview and execution reconcile identical candidate identities/counts.
• No binding implements recovery, reachability, delta replay, or compaction logic.
• Public docs include acknowledgement, retry, cancellation, and non-serializable optimistic behavior.

BDD Completion Scenarios

• Given the same mixed transaction in Rust, Python, Node, and CLI, when it commits, then each observes the same generation and result contract.
• Given a Node count above Number.MAX_SAFE_INTEGER, when maintenance progress is reported, then the value remains exact.
• Given a wrapper transaction is abandoned without commit, when the project reopens, then no staged mutation is visible.

Implementation Notes

Likely surfaces: PyO3 and napi bindings, CLI commands/contracts, public examples, and native-consumer acceptance. Wrappers must remain thin.

Observability

Parity for safe Rust fields only; no binding-specific payload logging.

Security And Privacy

No arbitrary cleanup path inputs, wrapper-side filesystem access, or exposure of graph content in errors/progress.

Testing

Rust/binding/CLI contract fixtures, clean-process reopen, cancellation, dropped-handle cleanup, large integer fields, and exact error parity.

Non-Goals

A binding-specific transaction engine or server protocol.

Related Issues

Canonical tracker: #747. Implemented against the Rust transaction and maintenance facade delivered with #751 and #754; #753 remains related follow-on bounded compaction work, not a prerequisite for this completed binding surface. Adjacent M5 parity issue: #744.