Cannot use KV store (or SDK) while database is mounted via NFS

[pkondzior]

Problem

When an AgentFS database is mounted via agentfs mount --backend nfs, the SQLite database file is exclusively locked by the mount process. Any attempt to open the same database from another process (or connection) even just for KV read/write fails immediately with:

database error: Locking error: Failed locking file. File is locked by another process

This makes it impossible to use the SDK's KV store, tool call tracking, or any other database-backed feature alongside a mounted filesystem.

A host application that runs an AI agent needs both:

1. Mounted filesystem — so the agent can read/write files via standard shell commands
2. KV store access — so the host can persist session metadata (e.g. suggestion state, review data, tool call tracking)

These are independent concerns sharing the same database. The filesystem serves file I/O, the KV store serves application state. But since mount holds an exclusive lock, the host process cannot access KV at all.

Reproduction

# Terminal 1: mount the database
agentfs mount -f --backend nfs ./my-agent.db /tmp/agentfs-mount

// Terminal 2: try to use KV on the same database
use agentfs_sdk::{AgentFS, AgentFSOptions};

#[tokio::main]
async fn main() {
    // This fails with "Locking error: Failed locking file"
    // while the mount process is running.
    let agent = AgentFS::open(AgentFSOptions::with_path("./my-agent.db"))
        .await
        .expect("failed to open AgentFS");

    // Never reached — even a read-only KV get is impossible.
    let value: Option<String> = agent.kv.get("my-key").await.unwrap();
    println!("value: {:?}", value);
}

Error: database error: Locking error: Failed locking file. File is locked by another process

Even KvStore::new("./my-agent.db") standalone (without full AgentFS::open) fails with the same lock error, since both paths open a new turso/libsql connection to the same file.

Current workaround

I've embedded the NFS server directly in the host process by vendoring nfsserve and AgentNFS from the CLI crate. This gives a single AgentFS instance that serves NFS and provides KV access through the same connection - no lock contention. It works, but requires vendoring ~3500 lines of NFS protocol code from the CLI.

Are there any plans to expose nfsserve + AgentNFS as a library crate** ? This would let SDK consumers embed the NFS server in their own process. This matches the singleton pattern from the official examples and is the most flexible option.

I'd be happy to contribute a PR for (exposing nfsserve + AgentNFS as a library crate). I've already done this work in my own project - vendoring the NFS server and adapter into a Rust application that embeds the mount alongside direct KV access. I can extract and clean up that work into a proper reusable crate if the maintainers are interested in this direction.