Module locking 

Intent-lock hierarchy adapter — Resource naming + LockerGuard RAII.

Thin layer over crate::storage::transaction::lock::LockManager that gives the runtime dispatch paths a typed API:

• Read dispatch: (Global, IS) → (Collection, IS)
• Write dispatch: (Global, IX) → (Collection, IX)
• DDL dispatch: (Global, IX) → (Collection, X)

The adapter owns:

1. A Resource enum that maps the two hierarchy levels to the byte-key format LockManager expects (no string collisions, cheap encoding).
2. A LockerGuard that records each (resource, mode) pair in acquisition order and releases them on drop. Releases run in reverse order so the global lock is the last to go.
3. A tiny monotonic TxnId allocator keyed by the current connection id — enough for deadlock detection to distinguish concurrent acquirers.

The adapter does not implement ordered-acquire enforcement via phantom types yet (TODO for P1.T4); callers currently discipline themselves by always going Global → Collection.

Structs

LockerGuard

RAII guard over a set of acquired locks. Drop releases every acquired resource in reverse-acquire order, so the common Global → Collection path releases Collection first then Global.

Enums

AcquireError

Outcome of a try_acquire — Granted / Upgraded fall through to the guard, the rest bubble up as an error the caller can log or retry.

Resource

Hierarchical resources the runtime locks on. The byte-key encoding prefixes each level with a discriminator so Collection("global") can never collide with the true global-scope Resource::Global.

Functions

fresh_txn_id