Feat: add purego ext 5 over koalabear and babybear fields

[yelhousni]

Description

We might need extension 5 over koalabear instead of 4 for higher security. This PR implements purego ext 5 over koala/baby bears, using naive, Montgomery-5 and ElMraber-Guillevic-Ionica algorithms.

Type of change

• New feature (non-breaking change which adds functionality)

How has this been tested?

Tests implemented in e5_direct_test.go in koalabear and babybear packages.

How has this been benchmarked?

So far for multiplication, Montgomery-5 is the fastest (also compared to Montgomery-6 and Toom-3/Karatsuba in #772)

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

---

Note

Introduce E5D (𝔽r⁵) for koalabear and babybear with naive, Montgomery-5, and interpolation mul; update docs, generator, and add tests/benchmarks.

• Extensions (babybear, koalabear):
  • Add E5D (𝔽r⁵) implementation in extensions/e5_direct.go with Add/Sub/Double/Mul/Square, including naive, mulMontgomery5, and mulElMGuiIon5 algorithms plus reduction rules (w^5=2 for babybear, w^5=w^2-1 for koalabear).
  • Add property tests and benchmarks in extensions/e5_direct_test.go validating algorithms and receiver behavior.
• Docs:
  • Update extensions/doc.go and doc.go.tmpl to document extension-5 definitions for babybear and koalabear.
• Codegen:
  • Update generator to emit e5_direct.go and tests for bear fields and run goimports in runFormatters.

^{Written by Cursor Bugbot for commit 028b3ac. This will update automatically on new commits. Configure here.}

[cursor]

Bug: evalAt returns zero instead of a0 for alpha=0

The evalAt function evaluates a polynomial at a given value alpha, but the case 0 branch returns a zero-initialized r instead of a.A0. Mathematically, A(0) equals a0, not zero. While the current implementation avoids this code path by using u[0].Set(&a.A0) directly with a comment // A(0), the function's behavior contradicts its documented contract if someone were to call evalAt(a, 0). The same issue exists in both babybear and koalabear implementations.

Additional Locations (1)

• field/koalabear/extensions/e5_direct.go#L625-L627