[unvetted AI slop] Use the Goppa polynomial base field

[Krastanov-agent]

Summary\n\n- build the default support from the Goppa polynomial's actual base field\n- add a regression using a noncanonical finite-field representation\n\n## Testing\n\nNot run locally; relying entirely on repository CI as requested.

[Krastanov-agent]

Why this fix is necessary

For a binary Goppa code, the polynomial and support must belong to the same concrete field:

g ∈ F[x]
L ⊆ F

The previous three-argument constructor discarded the field attached to g and independently created GF(2, m, :α). Although every field of size 2^m is abstractly isomorphic, Nemo field elements carry a specific parent and a specific polynomial representation. The integer m alone does not identify that parent or provide an isomorphism from a newly created field to the field of g.

As a result, the old constructor could create L in a different parent from the coefficients of g. That violates the constructor's mathematical contract and later reaches operations such as evaluate(g, o_i) in parity_matrix. Depending on the concrete field presentations, this can cause incompatible-parent errors or make the support use a representation unrelated to the polynomial's field.

The authoritative field is already available as base_ring(parent(g)). Enumerating that field guarantees that every support element can be evaluated by g without an implicit or guessed field conversion.

Why the existing tests did not catch it

Most Goppa coverage bypassed this code path:

• Random-code generation constructs g and L together and calls the four-argument constructor.
• The reference examples with an explicit L also build the support from the same F as g, then call the four-argument constructor.

The two existing examples that did use the default-support constructor created their polynomial field with the same (2, m, :α) presentation that the implementation hard-coded. That special case masks the unsupported assumption. Those tests checked code length, rank, and parity-matrix properties, but never asserted the parent invariant

parent(a) === base_ring(parent(g))

for the generated support.

The regression in this PR checks that invariant directly. This matters even when two field presentations happen to produce the same numerical code parameters: the returned Goppa object must remain internally coherent and valid for subsequent Nemo operations.