turbine: accelerate 32+32 FEC generation and recovery

[7layermagik]

Summary

Improve Mithril's standard 32 data + 32 coding shred path from block construction through repair recovery:

• target two complete FEC payloads when block production flushes entry batches;
• reuse the fixed-shape Reed-Solomon encoder and remove generated-shred parse/copy churn;
• mark DATA_COMPLETE_SHRED only at the actual end of a component spanning multiple FEC sets;
• add a setup-free exactly-one-missing-data recovery path for the fixed 32+32 matrix;
• add a deterministic repair simulator that exercises production generation, validation, spooling, repair selection, recovery, and completion;
• retain reduced multi-missing and all-coding implementations as measured experiments, without production dispatch.

This PR does not change the repair wire protocol, request signing, peer selection, or scheduler policy. Request-path work will be reviewed separately.

Motivation

The producer target previously represented two individual shred payloads rather than two complete 32-shred FEC payloads. That caused unnecessarily small entry batches. The generator also marked each FEC boundary as data-complete, which truncated components spanning multiple FEC sets.

On recovery, the general decoder pays matrix/setup and allocation costs when only one data shred is absent. For the invariant 32+32 matrix, that output has a direct GF(256) equation and can use process-wide precomputed coefficient rows without changing the encoded data or acceptance rules.

Production scope

The production recovery dispatch is deliberately narrow:

• exactly 32 data and 32 coding shards;
• exactly one absent data shard;
• at least one coding shard available.

All other erasure patterns continue through the existing reedsolomon.ReconstructSome path. The reduced multi-missing and coding-only paths remain test/benchmark evidence only.

Zen 5 results

Ryzen 7 9700X, Go 1.26.4, GOMAXPROCS=1, one pinned physical core. Repair-simulator values are medians of seven sequential one-second samples.

Benchmark	Before	After	Change
one-missing assembler boundary	10.73 us/FEC	2.82 us/FEC	-73.7% (3.8x)
near-tip repair simulation	3.0295 ms/op	2.8659 ms/op	-5.40%
deep-mixed repair simulation	4.0343 ms/op	4.0240 ms/op	-0.26%
deep-sparse repair simulation	10.8489 ms/op	10.8327 ms/op	-0.15%

The one-missing boundary drops from 144 to 5 allocations per operation. Deep-catch-up scenarios remain effectively neutral because they do not enter the specialized dispatch.

Correctness and auditability

• derive the direct row from the same systematic GF(256) matrix used by the general decoder;
• differential-test every 32 missing positions x 32 coding-row choices;
• compare the Cauchy closed form against an independent Gauss-Jordan inverse;
• verify destination atomicity on invalid or changed availability;
• compare reconstructed bytes with the existing general decoder;
• test the complete generated 32+32 SlotAssembler boundary;
• retain stable-byte generator fixtures and a multi-FEC component round trip;
• require canonical completed entry streams in the deterministic repair simulator.

Validation

Passed:

• go test -count=1 ./pkg/repair ./pkg/turbine/...
• go test -race -count=1 ./pkg/repair ./pkg/turbine ./pkg/turbine/internal/rsrecover ./pkg/turbine/repairsim
• go vet ./pkg/repair ./pkg/turbine/...
• git diff --check
• pinned Ryzen baseline/candidate A/B benchmarks above

A local go test ./... also passed the changed repair/turbine packages but is not globally green in this checkout because unrelated conformance/genesis fixtures are unavailable and existing lightbringer/sealevel tests fail.