nodedb_graph_insert_edge discards the created edge id that nodedb_graph_delete_edge requires

[emanzx]

Summary

nodedb_graph_insert_edge creates an edge and discards its id, while nodedb_graph_delete_edge requires exactly that id. An FFI caller can therefore create edges it can never individually delete.

Verified on origin/main @ ee9ccdd, nodedb-lite-ffi/src/ffi_graph.rs.

What happens

nodedb_graph_insert_edge calls the inner API and drops its result:

.block_on(h.db.graph_insert_edge(collection, &from_id, &to_id, edge_type, None))
{
    Ok(_) => NODEDB_OK,       // edge id created here is discarded
    Err(_) => NODEDB_ERR_FAILED,
}

nodedb_graph_delete_edge(handle, collection, edge_id) takes an edge_id string as its addressing key. There is no FFI query that returns edge ids for a (from, to, type) triple either, so the id is unrecoverable from the C surface: traversal results are the only place ids might appear, which makes "insert an edge, then delete it" impossible to do reliably.

Why it matters

Any binding exposing graph mutation ends up with an asymmetric API: insert works, targeted delete cannot be offered honestly. Our binding currently documents the limitation instead of exposing a broken delete-by-triple.

Suggested change

Return the id through an out-parameter, mirroring the existing convention used by nodedb_document_put:

int nodedb_graph_insert_edge(void *handle,
                             const char *collection,
                             const char *from, const char *to,
                             const char *edge_type,
                             char **out_edge_id);   // caller frees with nodedb_free_string

If ABI stability of the existing signature is a concern, a nodedb_graph_insert_edge_v2 (or ..._returning_id) alongside the old export works too; the old one can delegate and drop the id as it does today.