Fix tuple counts for reordered character tables

[fingolfin]

NumberGeneratingTuples took class positions from ConjugacyClasses(G) and passed them to TotalNumberOfTuples, which reads them as positions in CharacterTable(G). The two lists need not agree (GAP reference manual, "The Interface between Character Tables and Groups"): they differ when the class list stored in the group does not start with the identity class, and for non-supersolvable groups once the CCTab package is loaded. The count was then wrong, and GeneratingMCOrbits, which samples until it has accounted for that many tuples, returned too few orbits or did not terminate.

Take the classes from the character table, both for the group and for its maximal subgroups.

Assisted-by: Claude Code (Opus 5.5)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.15%. Comparing base (95aba43) to head (81315b2).

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #20      +/-   ##
==========================================
+ Coverage   56.02%   56.15%   +0.13%     
==========================================
  Files          17       17              
  Lines        1494     1494              
==========================================
+ Hits          837      839       +2     
+ Misses        657      655       -2     

Files with missing lines	Coverage Δ
lib/newgeneratingtuples.gi	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[shpectorov]

Thanks — the diagnosis looks right, and the fix is complete: TotalNumberOfTuples has
only three callers, and TotalNumberTuples in util.gi was already taking its classes
from the character table, so after this the three agree.

I went through this with Claude. The four expected values were checked independently
of GAP, by brute-force enumeration over S_4: 0 and 131040 for the transposition
tuples, 144 for (2,2,3,3), and 216 for genus 1 (the same under either commutator
convention). The orbit count follows from the third — those 144 tuples form six
classes of 24 under simultaneous conjugation, since a generating tuple has trivial
centraliser — so the expected values are correct. Merging.

One follow-up, if you have a moment. The test establishes that the two class orderings
differ and then records what the patched code returns. That pins the behaviour, but it
doesn't check the property the bug actually violated: that the answer should not depend
on the ordering. A comparison against the unpermuted group would, e.g.

gap> S:=SymmetricGroup(4);;
gap> NumberGeneratingTuples(S,[8],t8,0) = NumberGeneratingTuples(G,[8],t8,0);
true

That makes the test self-verifying rather than a snapshot.

Two unrelated things that came up in the same reading, which I'll open as issues
rather than clutter this one: generatingtuples.gi:302 has List(ccs, x -> Representative),
which maps to the function rather than calling it (harmless as used, but a trap); and
the IsPGroup branch in newgeneratingtuples.gi has two identical arms, so the promised
faster path for p-groups was never written.

Checked with Claude.