graph: bulk edge ingest has no batch form — every loader pays one statement per edge; add GRAPH INSERT/DELETE EDGES #369

Version / build tested against

origin/main @ 1ff3551

Deployment mode

Origin, single node (local)

Engine(s) involved

graph, pgwire

Summary

There is no batch form for edge writes at the SQL front door. Inside the
server, batch already exists end to end: the physical plan carries GraphOp::EdgePutBatch
and EdgeDeleteBatch, staging has stage_edge_put_batch, the WAL encode/decode pair
exists, and the data plane has execute_edge_put_batch and execute_edge_delete_batch.
The only missing link is the statement: parse_insert_edge builds a single-edge
GraphStmt::GraphInsertEdge, and the DDL dispatch handles one edge.

A bulk loader therefore has to send one GRAPH INSERT EDGE per edge, and a delete plus
insert pair per edge when it needs idempotent replay. A 66k edge import that should take
minutes takes hours, because every edge costs a full statement round trip and its own
apply burst. Because the lower layers already batch, I expect the change to be smaller
than it looks: statement variant, parser, and the DDL handler that reaches the existing
batch ops.

I say this as the author of a separate ETL tool, but the gap is generic: any graph
import, any migration, and any backup restore hits it. The deciding question I applied
when writing this: would a generic bulk client need it? Yes.

Steps to reproduce

-- seed two nodes, then time the per-edge form
GRAPH INSERT EDGE IN 'kg_code_edges' FROM 'a' TO 'b' TYPE 'CONTAINS';
GRAPH INSERT EDGE IN 'kg_code_edges' FROM 'a' TO 'c' TYPE 'CONTAINS';

Observed: one apply per statement, and at scale the write settles into single-digit
edges per second under pressure. A 66k edge drain, measured on this machine, ran for
hours with rate pacing to stay inside cluster pressure.

Expected behavior

One statement carries N edges. Proposal:

GRAPH DELETE EDGES IN 'kg_code_edges' VALUES
  ('a','b','CONTAINS'), ('a','c','CONTAINS');
GRAPH INSERT EDGES IN 'kg_code_edges' VALUES
  ('a','b','CONTAINS'), ('a','c','CONTAINS');

Semantics I would expect, and would document in the PR:

• One statement is one transaction, one apply burst, one response.
• RLS is evaluated per edge, exactly as the single-edge form does.
• A hard cap per statement, 1000 edges or 1 MiB of SQL text, whichever comes first,
  with a clear error when exceeded.
• Idempotency stays with the caller: delete batch then insert batch, which is what a
  loader already does today.

Also please expose it natively

The batch should be a native protocol op too (GraphOp::EdgeInsertBatch and
EdgeDeleteBatch or equivalent), not only a pgwire statement, so native clients get the
same capability without going through SQL text.

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong
• The server crashed, hung, or failed to start
• A security or isolation boundary was crossed
• Core functionality is broken with no acceptable workaround
• A workaround exists (send one statement per edge and pace the rate)

Proposed severity

SEV-3, feature gap with a workaround. Throughput only, no data risk.

Reproducibility

Always, every attempt.

Last known-good version / commit (if a regression)

Not a regression. The batch form never existed as far as I can find.

Environment & logs

Linux x86_64, single-node origin, trust mode, psql 16 and a Rust client over pgwire.
Bench numbers available on request; I will attach a before and after table in the PR if
someone picks this up, or in the issue if that helps triage.

Before submitting

• I searched existing issues and this is not a duplicate.
• I reproduced this on current main (not a stale branch).
• This is not a security vulnerability.

Consolidated from #373: test(graph): batch write paths need RLS and GRANT probes

#373 cannot land before this issue (no batch statement exists yet), and its RLS and GRANT probes are this feature's acceptance tests. They are now part of this issue's acceptance criteria. Closing #373 as a duplicate of this issue.