perf: enable thin LTO and single codegen unit for release builds

Release builds ran on cargo's defaults (16 codegen units, no LTO), so the
optimizer never saw across crate boundaries. The hot paths are spread over
several workspace crates and their dependencies -- SSZ encode/decode, hashing,
fork choice traversal -- which is exactly the shape that loses the most to
per-crate codegen units.

Adopt the same release profile ethrex uses: opt-level 3, thin LTO, one codegen
unit.

Clean `cargo build --release --bin ethlambda`, aarch64-apple-darwin, 11 cores,
isolated target dirs:

              wall     CPU    binary
  before    315.9s   1714s  30.6 MiB
  after     377.8s   1516s  26.6 MiB
             +20%     -12%      -13%

Wall clock grows because a single codegen unit serializes per-crate codegen,
even though total CPU work drops. CI's test job builds in release, so its
cold-cache builds get the same increase.

Runtime effect is not measured here: the repo has no benchmarks, and the
meaningful comparison (block build and aggregation latency) needs a devnet A/B.

Author: MegaRedHand

Cargo.toml

@@ -26,6 +26,16 @@ repository = "https://github.com/lambdaclass/ethlambda"
 rust-version = "1.92.0"
 version = "0.1.0"
 
+# Cross-crate inlining matters here: the hot paths (SSZ encode/decode, hashing,
+# fork choice traversal) are split across workspace crates and their
+# dependencies, so keeping every crate in its own codegen unit leaves inlining
+# opportunities on the table. Thin LTO plus a single codegen unit trades build
+# time for that, matching ethrex's release profile.
+[profile.release]
+opt-level = 3
+lto = "thin"
+codegen-units = 1
+
 [workspace.dependencies]
 ethlambda-blockchain = { path = "crates/blockchain" }
 ethlambda-fork-choice = { path = "crates/blockchain/fork_choice" }