perf(precompiles): add support for GLV strategy

[Nashtare]

Describe your changes

Add support for GLV strategy when computing MSMs.

Move the secp256k1 GLV endomorphism split from the ECDSA verifier's MASM/advice ABI into the precompiles prover's addition-chain strategy. ecdsa_k256_keccak::verify now always logs a plain u1*G + u2*Q claim
(Straus-shaped, no algorithm selector, no GLV advice), and the deferred prover satisfies it internally with a GLV-decomposed wNAF chain -- phi(P) is certified in-circuit via its value relation (x_phi = beta*x_P, y_phi = y_P), never trusted host advice.

Performance comparison between the two algorithms: https://claude.ai/code/artifact/b2e7a755-9313-4397-9810-eba22ab4a39e?via=auto_preview

MASM overhead is negligible (12 cycles for verify).

Checklist before requesting a review

• Repo forked and branch created from next according to naming convention.
• Commit messages and codestyle follow conventions.
• Commits are signed.
• Relevant issues are linked in the PR description.
• Tests added for new functionality.
• Documentation/comments updated according to changes.
• Updated CHANGELOG.md

[huitseeker]

Thanks! overall this looks super promising!!

[adr1anh]

The signed GLV algebra looks correct to me:

u ≡ sa·a + λ·sb·b mod n

and the implementation consistently applies each sign both to the MSM base and to the scalar-field recomposition. Here λ is the scalar-field eigenvalue; β is only used to construct φ(P) = (βx, y).

I have two main blocking concerns:

1. Valid zero GLV halves are always included in the 4-term MSM, but the curve precompile rejects zero-scalar terms. This can reject valid signatures.
2. I don’t think GLV hints should become part of encode_signature. Generating them through an event from the already-derived U1/U2 digests would preserve the signature API and avoid duplicating hashing, inversion, and scalar arithmetic.

There is also a mismatch between the PR description and the current branch: the description says selection remains manual and the benchmark uses Straus, while the implementation is now GLV-only and Straus is archived.

The remaining comments are documentation and MASM cleanup suggestions. There are also unrelated duplicate changelog entries, and the branch should be rebased rather than carrying the merge from next.

This was a static review; I did not compile or run tests.

[Nashtare]

Updated comparison against baseline. We now have GLV outperforming Straus in almost all cases and the delta is even larger for heavy batches (up to 36%)

[Nashtare]

@adr1anh I've revamped the approach to account for our latest discussion. The initial overhead of GLV is now basically removed (and the gains are even bigger). This should also make it much easier / cleaner to integrate non-GLV curves like secp256r1 or Curve25519 in the future.