accept numpy integers as node/edge ids

[TeunHuijben]

Closes #338

SQLGraph silently gave wrong answers when passed a numpy integer instead of a Python int:

g.has_node(node_id)              # True
g.has_node(np.int64(node_id))    # False

np.int64 is not a subclass of int, and sqlite3 doesn't know the type — it falls back to the buffer protocol and binds it as an 8-byte BLOB, which never compares equal to an INTEGER column. So lookups returned "not found" instead of raising. RustWorkXGraph accepted the same input fine, so the two backends disagreed. Since numpy integers come out of almost every numpy/polars call, callers were having to wrap ids in int() everywhere.

Affected SQLGraph paths, all silently wrong rather than raising: has_node, has_edge, edge_id, successors/predecessors, in_degree/out_degree, filter(node_ids=...), and attribute filters like NodeAttr("t") == np.int64(1).

Changes

• New utils/_numpy_native.py with is_int_like / to_native / to_native_list.
• SQLGraph converts ids and filter values before they're bound as SQL parameters.
• isinstance(node_ids, int) scalar-vs-sequence checks now use is_int_like, so a numpy scalar isn't mistaken for a sequence.
• graph.nodes[id] / graph.edges[id] accept numpy integers.
• Replaced 7 copies of hasattr(x, "tolist") with to_native_list, which also handles a plain list of numpy scalars (the old form only handled arrays).

Tests

test_numpy_integer_ids_* in test_graph_backends.py run against all three backends: 20 read paths asserted to give the same answer for int and np.int64, plus the write and bulk-add paths. 23 of them failed before this change.