feat(oblibeniser): implement Phase 1 — reversible operations, audit trails, undo/time-travel

Implement the core Oblíbený engine: manifest parsing for [project],
[[operations]], [audit], and [undo] sections; code generation for inverse
functions using mirror/log-replay/snapshot strategies; hash-chained audit
trail with tamper detection; undo/redo stack with configurable depth; and
time-travel debugging via snapshot-indexed history navigation.

- ABI: ReversibleOperation, InverseStrategy, AuditEntry, AuditTrail,
  UndoStack, UndoEntry, TimeTravel, TimeTravelStep, StateSnapshot
- Codegen: parser.rs, inverse_gen.rs, audit_gen.rs with full module output
- Manifest: project/operations/audit/undo TOML schema with validation
- Tests: 27 unit tests + 8 integration tests (all passing)
- Example: examples/reversible-db/ with 6 operations across all strategies

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: hyperpolymath

Cargo.lock

@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: PMPL-1.0-or-later
+= Reversible Database Example
+:author: Jonathan D.A. Jewell
+:email: j.d.a.jewell@open.ac.uk
+
+== Overview
+
+This example demonstrates how oblibeniser makes common database operations
+fully reversible using all three inverse strategies:
+
+[cols="2,1,3"]
+|===
+| Operation | Strategy | Rationale
+
+| `db_insert` / `db_delete`
+| Mirror
+| Insert ↔ Delete are algebraic inverses — deterministic reversal.
+
+| `db_update` / `db_batch_update`
+| Log-replay
+| Updates record old values in a mutation log and replay backwards to undo.
+
+| `schema_migrate` / `db_truncate`
+| Snapshot
+| Destructive operations capture full state before execution.
+|===
+
+== Usage
+
+[source,bash]
+----
+# Generate reversible wrappers from this manifest:
+oblibeniser generate \
+  --manifest examples/reversible-db/oblibeniser.toml \
+  --output generated/reversible-db
+
+# Inspect generated files:
+ls generated/reversible-db/
+# → inverses.rs  audit.rs  verify_audit.rs  summary.txt
+
+# View the generation summary:
+cat generated/reversible-db/summary.txt
+----
+
+== Audit Trail
+
+The audit trail uses hash-chaining (like a lightweight blockchain) to ensure
+tamper-evidence. Each entry contains the hash of the previous entry:
+
+....
+Entry[0]: hash=a1b2c3... prev=
+Entry[1]: hash=d4e5f6... prev=a1b2c3...
+Entry[2]: hash=g7h8i9... prev=d4e5f6...
+....
+
+If any entry is modified after the fact, the chain breaks and verification fails.
+
+== Undo Stack
+
+With `max-depth = 200`, the last 200 operations can be undone. The
+`auto-checkpoint-interval = 25` means a full state snapshot is taken every
+25 operations, enabling efficient time-travel to any point in history.

examples/reversible-db/README.adoc

@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: PMPL-1.0-or-later
+# Example: Reversible database operations via Oblíbený.
+#
+# This manifest demonstrates all three inverse strategies applied to
+# common database operations. Run with:
+#   oblibeniser generate --manifest examples/reversible-db/oblibeniser.toml
+
+[project]
+name = "reversible-db"
+version = "0.1.0"
+description = "A database layer with fully reversible CRUD operations"
+
+# INSERT: Mirror strategy — inverse is DELETE by key.
+[[operations]]
+name = "db_insert"
+forward-fn = "db::insert"
+params = ["table:String", "key:String", "value:Vec<u8>"]
+inverse-strategy = "mirror"
+
+# DELETE: Mirror strategy — inverse is INSERT with the deleted data.
+[[operations]]
+name = "db_delete"
+forward-fn = "db::delete"
+params = ["table:String", "key:String"]
+inverse-strategy = "mirror"
+
+# UPDATE: Log-replay strategy — records old values and replays them backwards.
+[[operations]]
+name = "db_update"
+forward-fn = "db::update"
+params = ["table:String", "key:String", "field:String", "new_value:String"]
+inverse-strategy = "log-replay"
+
+# BATCH UPDATE: Log-replay — records each individual change in the batch.
+[[operations]]
+name = "db_batch_update"
+forward-fn = "db::batch_update"
+params = ["table:String", "updates:Vec<UpdatePair>"]
+inverse-strategy = "log-replay"
+
+# SCHEMA MIGRATION: Snapshot — captures full DB state before migration.
+[[operations]]
+name = "schema_migrate"
+forward-fn = "schema::migrate"
+params = ["target_version:u32"]
+inverse-strategy = "snapshot"
+
+# TRUNCATE: Snapshot — only safe inverse is full state restore.
+[[operations]]
+name = "db_truncate"
+forward-fn = "db::truncate"
+params = ["table:String"]
+inverse-strategy = "snapshot"
+
+[audit]
+hash-chain = true
+storage = "file"
+max-entries = 50000
+
+[undo]
+max-depth = 200
+auto-checkpoint-interval = 25