Group the subgraphs found by shape, and draw them

[loloDawit]

Enumerating connected subgraphs is the first step of motif discovery. This is
the second.

The app reported {0, 1, 2} and {2, 3, 4} as two answers without ever saying
both are triangles — which is what a motif actually is. There was also nothing
to compare against a random network, because there were no shapes to count.

Both implementations get the feature: the desktop app on shortcut G, the
browser demo beside the graph.

Grouping

Shape.of finds a canonical form by brute force: every relabelling of a
subgraph's vertices is tried and the smallest adjacency bitstring kept. Two
subgraphs match when their canonical forms do.

Industrial tools use nauty, which earns its keep at the sizes they work at. A
subgraph here has at most a few vertices, so a few hundred relabellings cost
microseconds, need no C library, no JNI and no second port — and the method
fits in a sentence, which matters for a tool whose job is explaining.

Shapes are listed most frequent first, drawn, and named where people have a
name for them: triangle, path, star, cycle, diamond, clique.

Drawing what was found

A shape and a count still do not show you what the subgraphs look like, or that
they look like each other. Choosing a shape now draws every subgraph having it,
each keeping its real vertex numbers, in the same visual language as the input
graph. Identical shape, different vertices, which is the reason to group them.

Clicking one shows it in the input graph, so it is clear where in the network
that occurrence sits.

Every instance is shown whatever step is on screen: the shapes and their counts
describe the finished search, not how far the stepping has got. Selecting a
shape at step 9 of 38 would otherwise show an empty grid under a header saying
six.

Keeping the two implementations honest

java-golden.json now records, per graph and size, the shapes found: name,
edge count, how many, in what order, and the edges each one draws — 30 entries.
The Java classifier gained a fixed order among equal counts, since listing by
insertion order would differ between implementations for no useful reason.

What the tests learned

Four tests here were worthless as first written, and all four failed the same
way: the example chosen had too little variety to tell right from wrong.

• The invariance check used a complete subgraph, which is symmetric, so every
  relabelling gives the same answer whether the form is canonical or not. It
  passed against an implementation keeping an arbitrary relabelling.
• The drawing check ran against a graph with a single shape, so "every shape
  draws differently" was true of anything.
• Fixing that, it still only checked distinctness — and three wrong drawings
  are still three different drawings.
• The demo's instance count would have passed had the chosen shape occurred
  once, so it now insists on more than one.

Two bugs are covered by different tests, neither catching the other's: every
pair reading the same bit fails the DOM check, which counts lines drawn against
the edges a shape claims (star drew 6 edges, expected 3); the bit order
reversed fails 11 equivalence cases, which an edge count cannot see because
reversing preserves how many bits are set.

65 Java tests, 94 TypeScript.