Abstract RGB File Persistence to KVStore

This proposal discusses abstracting the RGB-related file persistence in lightning/src/rgb_utils/mod.rs to use the existing KVStoreSync trait instead of direct filesystem operations. This would allow RGB data to be stored in a database (or any KVStoreSync implementation) alongside other LDK data.

Currently, RGB-related data is persisted directly to the filesystem using std::fs operations, while other LDK data (channel monitors, channel manager, etc.) uses the KVStoreSync trait abstraction. This creates an inconsistency:

• LDK data: Uses KVStoreSync → can be backed by filesystem, database, or custom storage
• RGB data: Hardcoded to filesystem → limited to file-based storage only

For applications that want to use a database backend (e.g., SQLite via Sea-ORM) for all LDK persistence, the RGB files remain on the filesystem, requiring hybrid storage management.

Proposal

• Refactor RGB persistence functions to use KVStoreSync with RGB-specific namespaces or fallback to fs for backwards compatibility.
• Functions would change from path-based to KVStore-based or keep both for backwards compatibility.

The main question for discussion is whether this change should be backwards compatible or a clean break.

Once we agree on the approach, I can prepare and submit a PR.

Start with lightning/src/rgb_utils/mod.rs and compare its std::fs persistence with existing KVStoreSync implementations used for channel monitors and the channel manager. Resolve whether storage should use RGB-specific namespaces, retain filesystem fallback, or make a clean break. Done means the agreed persistence approach supports the intended KVStoreSync backend and its compatibility behavior is documented.