feat(dbtool): add proof domain for proofs and remote-prover bookkeeping

[vladb-ai]

Replicated from alpenlabs#172

Description

Extends dbtool with a proof domain so the runner's proof DB can be inspected and maintained offline, the same way the existing asm domain covers the storage DB. Previously there was no offline tooling for any of the prover's on-disk data.

The domain, all in the proof DB:

• proof asm — ASM step proofs, keyed by L1 range. get <range> · list · delete <range>.
• proof moho — Moho recursive proofs, keyed by commitment. get · latest · list · delete.
• proof mapping — the local↔remote proof-id mapping. get-remote <proof_id> · get-local <remote_id> · list.
• proof status — in-flight remote job status. get · list · in-progress · delete.
• proof prune --before <h> — drops ASM and Moho proofs below a height (leaves the mapping/status bookkeeping untouched).

Proof values are borsh-encoded (each wraps a ProofReceiptWithMetadata), so records carry a lossless borsh_hex blob rather than the ssz_hex the asm records use. Ranges (<commitment>..<commitment>), proof ids (asm:<range> / moho:<commitment>) and remote ids (hex) each render in the exact string a verb parses, so a printed record feeds straight back into the next command. Mutating verbs stay behind the --write gate.

To keep dbtool fully synchronous (no tokio runtime, matching the asm commands), SledProofDb gains synchronous inherent accessors across all five trees — get/store/prune plus the previously-missing list/delete — with the async storage-trait impls delegating to them, mirroring the sync-variant convention already used in strata-asm-moho-storage.

Independent of the Moho dbtool PR (alpenlabs#171); both branch off main, so whichever merges second rebases the shared dbtool files.

Type of Change

• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Documentation update
• New or updated tests

Notes to Reviewers

SledProofDb's async trait impls now delegate to the new sync methods; the existing storage-crate proptests (unchanged behaviour) plus new list/delete tests cover them.

Verified end-to-end against a real proof DB through the built binary for the read/empty/write-gate paths; the functional test (fn_asm_dbtool_proof_test.py) drives the prover env until proofs land and then exercises list/get round-trips, latest, missing lookups, the empty remote bookkeeping the native backend leaves behind, the --write gate, and a delete on a snapshot.

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

[github-actions]

🔒 AI Security Review

I reviewed the diff (gh pr diff 4) plus the surrounding code in bin/dbtool/ and crates/extensions/prover/storage/ for injection, auth, crypto, memory-safety, and DoS issues.

No exploitable vulnerabilities found.

Notes on why the usual risk areas don't apply here:

• Scope/trust boundary: dbtool is an offline, operator-run CLI against a local sled DB the runner itself created (bin/dbtool/src/db.rs rejects a missing directory rather than materializing one). It has no network listener and no remote input — the only untrusted input is CLI argument strings, and the only "attacker" would be someone who already has filesystem access to the machine and its data directories, at which point the DB itself is already compromised.
• CLI parsing is panic-free on malformed input: parse_commitment, parse_range, parse_remote_id, parse_proof_id (bin/dbtool/src/utils.rs) all return Result/Context on bad input rather than panicking — including L1Range::new, which returns None (mapped to an error) rather than panicking when end < start.
• Write-gating is correctly threaded: every mutating verb (proof asm delete, proof moho delete, proof status delete, proof prune) calls ensure_write(write)? before touching the DB (bin/dbtool/src/cmd/proof.rs), consistent with the existing asm domain's gate, so --write can't be bypassed for the new resources.
• .expect() panics are confined to self-written data: the new list_asm/list_moho key-decoding and the borsh try_from_slice(...).expect(...) calls in crates/extensions/prover/storage/src/sled/proof_db.rs, remote_mapping.rs, and remote_status.rs only ever deserialize bytes that this same code previously wrote via encode_asm_key/encode_moho_key/borsh::to_vec. They are not reachable with attacker-supplied bytes through any path added in this PR.
• No new deserialization-from-network path: this PR only adds synchronous wrappers around the pre-existing async ProofDb/RemoteProofMappingDb/RemoteProofStatusDb trait methods, plus list_* enumeration. It doesn't change how remote-prover responses are ingested or deserialized, so it doesn't expand the untrusted-input surface for that data.

Nothing else in the diff (Cargo.toml/Cargo.lock dependency additions, README updates, cli.rs clap enum additions, functional test additions) has security relevance.