[DB-007] Create StorageBackend trait abstraction

[umwelt]

Priority: HIGH

Phase: 3 - lib-storage Persistence Backend

Problem

lib-storage currently uses in-memory HashMap with full-state file serialization. This doesn't scale and lacks backend flexibility.

Affected Files

• lib-storage/src/backend/mod.rs (new)
• lib-storage/src/backend/traits.rs (new)

Proposed Design

use async_trait::async_trait;

#[async_trait]
pub trait StorageBackend: Send + Sync {
    /// Store a key-value pair
    async fn put(&self, key: &[u8], value: &[u8]) -> Result<()>;

    /// Retrieve a value by key
    async fn get(&self, key: &[u8]) -> Result<Option<Vec<u8>>>;

    /// Delete a key
    async fn delete(&self, key: &[u8]) -> Result<()>;

    /// Check if key exists
    async fn contains(&self, key: &[u8]) -> Result<bool>;

    /// Iterate over keys with prefix
    async fn scan_prefix(&self, prefix: &[u8]) -> Result<Vec<(Vec<u8>, Vec<u8>)>>;

    /// Batch write operations
    async fn write_batch(&self, ops: Vec<BatchOp>) -> Result<()>;

    /// Flush to disk
    async fn flush(&self) -> Result<()>;
}

pub enum BatchOp {
    Put { key: Vec<u8>, value: Vec<u8> },
    Delete { key: Vec<u8> },
}

Benefits

1. Backend flexibility - Swap sled/SQLite/memory without code changes
2. Testing - Use memory backend in tests
3. Future-proofing - Easy to add new backends
4. Separation of concerns - Storage logic decoupled from persistence

Acceptance Criteria

• Trait defined with comprehensive operations
• BatchOp enum for atomic operations
• Async-first design
• Documentation with examples

Related

• Part of storage layer overhaul: docs/architecture/STORAGE_OVERHAUL.md
• Enables: DB-008, DB-009