edge list: no filters — every question needs a client-side pass over all of a node's edges

[shadowbrush]

hadron edge list takes a node and returns every edge in both directions. Its entire flag surface:

Flags:
  -h, --help            help for list
  -m, --memory string   memory (org::memory) to resolve a bare <loc> against

So any question narrower than "all edges of this node" has to be answered by piping --json into a script.

What that looked like in practice

Building and then running hadron coding review|preflight lint (#325/#328/#332), I wrote the same shape of one-off filter around a dozen times:

# "which checks hang off the review parent, and what are their trigger labels?"
hadron edge ls review -m micromentor.org::mmdata --json \
  | python3 -c "…[e for e in json.load(sys.stdin) if e['direction']=='incoming']…"

# "which preflight routes aren't action-phrased?"
hadron edge ls preflight -m hadronmemory.com::dev --json \
  | python3 -c "…[e for e in … if e['direction']=='outgoing' and not e['name'].startswith('to ')]…"

# "what's the edge id for the route to findings:X?"
hadron edge ls preflight -m … --json | python3 -c "…"

Every one of those is a --direction and/or a --name filter away from being a plain command. The router in hadronmemory.com::dev has 20 edges; mmdata's preflight has 75. Reading all of them to look at a handful is the normal case, not an edge case.

It also makes the CLI awkward to recommend for exactly the audit work coding lint exists to support: filing hadron-server#845 and hadron-server#850 meant extracting edge ids and labels by script, and any human following those issues has to do the same to check my numbers.

Suggested flags

Modest and composable:

• --direction incoming|outgoing — by far the most common need; both linters key off it, and the two sides mean different things (see docs/plans/coding-command-group.md Decision 3)
• --name <substring> — or --name-prefix, to answer "which edges are labelled routes-to"
• --to <ref> / --from <ref> — filter by the far endpoint

I reached for --to first and got unknown flag: --to, which is what prompted this.

Notes

• Purely client-side filtering over what GetNode already returns — no new query, no server change.
• Should preserve the existing --json row shape (id, direction, name, loc, isRunnable, priority, otherNodeId, otherNodeLoc) so existing scripts keep working; filters only reduce the rows.
• Worth pairing with node refs: the CLI prints node ids it then refuses to accept #336: with both, hadron edge ls <id> --direction incoming --name routes-to becomes a single command instead of a script plus a URN round-trip.