[b84330808]

Graphs.hasCycle returns false for some undirected graphs that do have a cycle:

MutableGraph<String> graph = GraphBuilder.undirected().build();
graph.putEdge("a", "b");
graph.putEdge("b", "c");
graph.putEdge("c", "a");
graph.addNode("x");
graph.addNode("y");
Graphs.hasCycle(graph); // false; 32.1.3 returns true

This came in with 63734b9 (iteration instead of recursion, to avoid StackOverflowError), so 33.3.0 through 33.6.0 are affected.

In subgraphHasCycle, when the next successor is the node we just came from (the undirected A->B->A case that canTraverseWithoutReusingEdge rejects), the loop falls through to stack.removeLast() and marks the node COMPLETE, so the rest of its successors are never visited. The recursive version only skipped that one successor. Connected graphs with a cycle still hit the numEdges >= nodes().size() shortcut, which is probably why the existing tests didn't catch it; it shows up once there are more nodes than edges.

The fix moves the continue out of the if, so only the rejected successor is skipped.

The new GraphPropertiesTest.hasCycle_threeCyclicEdgesAndIsolatedNode fails before the change and passes after, and the rest of com.google.common.graph passes. A randomized comparison against a plain recursive DFS on 20,000 small graphs (directed/undirected, with and without self-loops) found 456 wrong answers before the change and none after. I left android/ alone per CONTRIBUTING.

Unrelated, but nearby: hasCycle_deepPathGraph adds the 100,000-edge path to graphsToTest and then asserts on directedNetwork/undirectedNetwork, which are empty, so it doesn't actually check the deep-path graph case. Happy to fix that here or in a separate PR.

I used Claude Code to write this change.