refactor(akita-field): Land Solinas field from akita-field in Jolt's jolt-field

[Acentelles]

Summary

This PR integrates akita-field crate into the Jolt's jolt-field crate. It updates every Akita crate, test, example, benchmark, fuzz target, and profiling workspace accordingly.

The purpose is to reduce the field arithmetic audit surface. Field arithmetic moves to jolt-field, while Akita continues to own its protocol errors, validation policy, and optimized serialization format.

Changes

• Replace all akita_field imports and manifest dependencies with direct jolt_field imports.
• Enable jolt-field/solinas for Akita consumers and propagate jolt-field/parallel only through Akita's existing parallel features.
• Add the Akita-owned akita-error crate and move AkitaError into it. Convert jolt_field::FieldError to AkitaError at the protocol boundary.
• Move the existing field serialization and validation implementations into akita-serialization/src/field_impls.rs.
• Delete crates/akita-field, its compatibility facade, and Akita's duplicate field arithmetic benchmark.
• Update workspace and auxiliary lockfiles, fuzz and profiling manifests, CI, the Akita Book, specifications, crate graph, and verifier documentation.
• Remove the obsolete akita-field/jolt-compat adapter test job.

Testing

• Ran the Akita test suite with cargo test.
• Ran the focused serialization suite with
  cargo test -p akita-serialization.
• cargo clippy --all --message-format=short -q -- -D warnings passes.
• cargo fmt --all --check passes.
• ./scripts/check-doc-guardrails.sh passes.
• ./scripts/check-shared-field-identity.sh reports exactly one
  jolt-field identity and no akita-field package.
• git diff --check passes.

The completed test suite includes Akita's unit, integration, end-to-end, and documentation tests. Serialization coverage checks fixed prime-field bytes, extension coefficient order, validated decoding, reported size, and round-trip behavior.

Security Considerations

This PR changes the ownership and dependency path of security-sensitive field arithmetic used by the Akita prover and verifier. It does not intentionally change the arithmetic: field moduli, canonical representations, extension bases, reductions, FFT parameters, and packed kernels come from the same implementation moved into jolt-field by a16z/jolt#1684.

Akita's optimized field serialization remains Akita-owned.

The new akita-error crate preserves the existing protocol error variants.

The package identity CI guard prevents both field implementations from re-entering the dependency graph. This PR does not intentionally change proof soundness, verifier acceptance rules, private-input handling, proof bytes, or the Akita transcript schedule.

Breaking Changes

• Removes the public akita-field package and its jolt-compat feature.
• Changes field type paths from akita_field::* to jolt_field::*.
• Changes the protocol error path from akita_field::AkitaError to akita_error::AkitaError.
• Downstream Akita workspace consumers must depend on the pinned jolt-field package and enable the required Solinas feature.

[Acentelles]

We need to wait for a16z/jolt#1684 to be merged first

[quangvdao]

The architectural direction looks right: jolt-field should be the single owner of the shared arithmetic stack, while Akita retains its protocol errors, validation policy, and wire serialization. The source-level split is also sensible: delete akita-field, define AkitaError once in akita-error, and implement Akita’s serialization traits for the Jolt-owned field types in akita-serialization.

I am requesting changes because the current branch is an intermediate migration snapshot rather than a mergeable Akita change. This review is against Akita head 57276e9830d342817abc2f8e0ddda7edc38596e8, current Akita main f5c180a49a83f5ce3e8b683a34208166ffed2f66, and Jolt PR #1684 head 09b2f7b6ddd9427c756b781c39530a6c005e332d.

Required before this can merge

1. Land and freeze the Jolt field source first

This PR currently pins:

https://github.com/Acentelles/jolt.git
rev = 09b2f7b6ddd9427c756b781c39530a6c005e332d

That is appropriate for stacked review, but not as Akita’s landed production dependency. Please:

• get Jolt #1684 reviewed and merged;
• replace every contributor-fork pin with either the immutable upstream merge revision or a released jolt-field package;
• regenerate all root, fuzz, and profiling lockfiles from that final identity;
• confirm that all Akita workspaces resolve the same package ID.

If the Jolt PR changes after this review, please identify the arithmetic/trait delta from 09b2f7b6… rather than silently advancing the pin.

2. Rebase onto current Akita main

The PR merge base is 3b674abb66186037745af256e6a20d60bdcd7e89. Current main has since landed #302 and #294. A merge simulation reports 35 conflicts, including config, planner, setup, prover, verifier, and setup-contribution files.

Please rebase after the Jolt source is frozen and preserve the post-#294 architecture. The result should apply the field-ownership cutover to the current APIs rather than restoring pre-#294 files while resolving conflicts.

Because this affects hundreds of generic bounds and imports, please inspect the final main...HEAD diff again after the rebase; validation on the present pre-rebase tree will not be sufficient evidence for the final tree.

3. Fix the shared-field identity guard

The new identity script fails under the workflow’s actual environment. CI sets CARGO_TERM_COLOR=always, but the script only removes an uncolored (*) marker. I reproduced:

CARGO_TERM_COLOR=always scripts/check-shared-field-identity.sh
error: expected exactly one jolt-field package identity, found 2

The two reported lines are the same package identity; the second merely has an ANSI-colored (*). With CARGO_TERM_COLOR=never, the script passes.

Please make this check structural and color-independent. Prefer parsing cargo metadata package IDs; at minimum invoke Cargo with --color never before parsing. Add a regression test that runs with the repository’s CARGO_TERM_COLOR=always setting.

The corresponding check in Jolt #1684 has the same defect and is currently red.

4. Add cross-revision golden compatibility fixtures

The new serialization module has useful fixed prime-byte and extension coefficient-order tests, and the existing round-trip tests continue to run against the new types. However, that is not enough to substantiate the broader claims that proof bytes, setup bytes, transcript challenges, and validation behavior are unchanged.

Please add fixtures generated by the pinned pre-cutover Akita revision and consumed by the post-cutover implementation. They should cover, at minimum:

• canonical boundary encodings for every production prime-field width;
• extension coefficients in the exact Akita wire order;
• validated rejection of noncanonical encodings;
• deterministic commitment/setup serialization;
• at least one deterministic complete proof serialization;
• transcript absorption and resulting challenge bytes for a fixed schedule.

The expected bytes should come from the old implementation or a checked-in pre-cutover artifact, not be generated and blessed by the new implementation in the same test. If any of these are intentionally deferred, narrow the PR’s compatibility claims accordingly.

5. Make the staged Jolt state and cleanup obligation explicit

Jolt #1684’s current description says that jolt-field/src/akita.rs, the akita feature, and Akita dependencies are deleted. At its actual head they are intentionally retained as bootstrap wiring. jolt_akita::AkitaField also still routes through the pre-cutover Akita configuration.

The latest Akita spec explains the staged state more accurately. Please:

• correct the Jolt PR description to match its actual head;
• update the spec metadata to name Akita PR B as refactor(akita-field): Land Solinas field from akita-field in Jolt's jolt-field #307;
• link the issue or PR that will implement Jolt PR C;
• describe how PR C will patch Akita’s immutable jolt-field dependency back to Jolt’s workspace member without producing two Cargo package identities;
• keep the adapter/bootstrap deletion acceptance item unchecked until PR C actually lands.

This cleanup should be treated as part of the migration, not an optional later refactor.

6. Produce fresh final-head validation

Akita #307 currently has only external security scans attached; its normal format, clippy, test, documentation, and shared-field jobs have not run on this head. Jolt #1684 also currently has five failed checks:

• shared-field identity;
• Criterion benchmark feature selection;
• jolt-field fuzz compilation;
• Taplo formatting;
• typos.

Please make the Jolt prerequisite green, then rerun Akita validation on the rebased tree with the final upstream dependency:

• cargo fmt --all --check
• cargo clippy --all --message-format=short -q -- -D warnings
• cargo test
• ./scripts/check-doc-guardrails.sh
• the corrected shared-field identity check
• git diff --check

Please also report the exact final Akita and Jolt SHAs. Results from 57276e98 or from the contributor-fork field identity should not be carried forward after the rebase or dependency replacement.

What does not need changing

I do not think we should retain an akita-field re-export facade or compatibility wrapper. Akita explicitly makes no backward-compatibility guarantee, and direct jolt_field::* imports are the cleaner final API.

Likewise, keeping serialization and AkitaError on the Akita side is the correct ownership boundary. The requested changes are about making the cross-repository landing atomic enough to audit, proving byte compatibility, and ensuring the final dependency graph—not reversing the architecture.

[Acentelles]

Saving the merge conflicts, I've addressed your comments @quangvdao