Accept the family names printed on group pages in the abstract groups jump box

[roed-math]

Follow-up to #7149, and stacked on it: this branch has #7149's commit as its parent, so the second commit is the change to review here. Once #7149 merges, this diff reduces to that commit.

Reported by @jenpaulhus in #7149 (comment): typing GO(5,3) into the abstract groups jump box says "is not a valid name for a group or subgroup", even though 103680.a is in the database and its own page prints that name.

What was wrong

group_jump matches the input against the input regexes in gps_families, which spell each family the way it is stored. Neither name printed on a group page always agrees with that spelling:

• the Groups of Lie type row prints the family's tex_name. For the orthogonal and unitary families that uses other letters (Orth prints as O, GOrth as GO, Unitary as U, GUnitary as GU), and the Plus and Minus families print with a +/- exponent.
• the Magma/GAP/Sage/Oscar snippets print magma_cmd, which differs again: Orth is Magma's GO, GOrth is Magma's CO, GSO is CSO, GSp is CSp, PO is PGO, PU is PGU.

So https://www.lmfdb.org/Groups/Abstract/103680.a displays O(5,3) and GO(5,3) in its Lie type row, and G := GO(5,3); and G := CO(5,3); in its code snippets. Before this change none of those four strings could be pasted into the jump box:

O(5,3)      -> rejected        Orth(5,3)      -> 103680.a
GO(5,3)     -> rejected        GOrth(5,3)     -> 103680.a
U(3,3)      -> rejected        Unitary(3,3)   -> 24192.a
GU(3,3)     -> rejected        GUnitary(3,3)  -> 48384.a

What this does

Adds FAMILY_NAME_ALIASES, which rewrites the family part of a Fam(n,q) name onto the stored spelling before the gps_families regexes are tried:

• the printed names O, O+, O-, GO, GO+, GO-, U, GU, and +/- in place of Plus/Minus for SO, GSO, PSO, PO, Omega, POmega and Spin;
• the Magma names CO, COPlus, COMinus, CSO, CSOPlus, CSOMinus, CSp, CSU, CU, PGO, PGOPlus, PGOMinus, PGU, where that spelling is not already in use.

GO(5,3) and O(5,3) now both reach 103680.a.

The one judgment call

Magma's GO, GOPlus, GOMinus and GU are deliberately not accepted. We use the G prefix for similitude groups, consistently across Sp/GSp, SO/GSO, SU/GSU, U/GU and O/GO, whereas Magma uses G for isometries and C for similitudes. So LMFDB's GO(n,q) is Magma's CO(n,q), and reading GO Magma's way would silently return a different group from the one the page shows under that name. GO therefore resolves to GOrth.

For n = 5, q = 3 the two readings coincide anyway: for odd n every similitude factor is a square, so CO(n,q) = F_q^* . GO(n,q) with intersection {+/-1} and |CO| = |GO| . (q-1)/2, which at q = 3 is |GO|. That is why 103680.a is stored under both Orth and GOrth. Happy to flip the convention if the group folks would rather match Magma.

Notes

• Purely additive: no alias is an existing family name (asserted in test_family_name_aliases_are_unclaimed), so every input accepted today matches exactly as before, and the error messages keep the user's own spelling rather than the rewritten one.
• Tested by test_family_name_alias_lookup, with one stored example per alias, kept in sync with the table by an assertion.
• Not covered here, because they need argument rewriting rather than a prefix substitution: Magma's constructor-style names (Sym(n), AlternatingGroup(n), CyclicGroup(n), DihedralGroup(n), DicyclicGroup(n), ChevalleyGroup(...)).

🤖 Generated with Claude Code

[jenpaulhus]

LGTM. I agree that we have decided not to default to Magma naming convention and so I agree with the choices Claude made here.

I do not think we should bother to accept magma commands like AlternatingGroup(n) in this box.