start storage transaction

Opens a storage transaction: every document create, update, remove and restore this flow performs until the end block is journaled so the whole group can be reverted as one.

Opens a storage transaction for the rest of this flow (and every function it calls). While it is open, every store write : function_create_*, function_update_*, function_remove_*, function_restore_*, function_delete_document, upserts : records the document's state BEFORE the write into a Redis journal, and created documents carry _meta.transaction_id. function_transaction_revert then undoes the journal newest-first, refusing any document whose update_hash moved since; function_transaction_end commits it and stores `result`. NOT an ACID transaction: writes are visible immediately, and bulk ES operations (update by query, reindex, bulk delete) fail with TRANSACTION_UNSUPPORTED_WRITE while one is open. A transaction is identified by the id AND the blueprint that started it (the `transaction_ref` out-pin is the qualified form), so another blueprint cannot read or revert it by guessing the id. With a stable `id` (an order number, account+season) it is also an idempotent-retry gate: a second start of an id that already committed answers already_committed=true with the stored result and does not reopen; one whose previous attempt is still running (its lease is alive) fails with TRANSACTION_IN_PROGRESS; one whose previous attempt died (lease expired) is reverted first when revert_abandoned is on (default) : status revert_conflict and TRANSACTION_REVERT_CONFLICT when that revert could not complete : or fails with TRANSACTION_ABANDONED when it is off. status is one of started, already_committed, in_progress, abandoned, revert_conflict; success is true only for started and already_committed. The journal is kept for `retention` seconds (default 7 days); `lease` seconds (default 60) is how long a crashed opener is still considered alive. In simulation nothing is written and status is simulated.