core: switch calls to std::byteswap to bswap

[goodlyrottenapple]

No description provided.

[github-actions]

Refactor is clean and correct. The monad::bit::byteswap indirection is a tidy way to substitute a libgcc-free implementation for the zkVM (riscv64ima) guest without perturbing host callers, and the mechanical rename of remaining call sites from std::byteswap to bswap keeps the layering (bit::byteswap for category/core/runtime/, bswap for everything else) consistent.

Verified in zkvm/category/core/runtime/bit.hpp:

• The 8-byte SWAR sequence reduces 0x0102030405060708 to 0x0807060504030201 (traced by hand).
• The 4-byte sequence is the standard 8/8/16 pattern.
• The sizeof(T) != 4 && sizeof(T) != 8 fallback to std::byteswap covers uint16_t (which GCC inlines even without rev8) and 1-byte cases (identity).

No FFI / RLP semantics change on the host: bswap produces bit-identical output to std::byteswap for all migrated call sites, so consensus / wire encodings are unaffected.

The category/mpt/util.hpp refactor is functionally equivalent to the previous cascade of __builtin_bswap{16,32,64}; as a bonus, it silently fixes a latent uint8_t bug where the old __builtin_bswap16(n) assigned back into a uint8_t would zero the value (no current callers exercise sizeof==1, so no observable behavior change).

No new tests, but existing coverage in test/vm/unit/uint128_tests.cpp, test/vm/unit/uint256_tests.cpp, and test/vm/unit/runtime/transmute_tests.cpp exercises bswap / byteswap through the same code path on host builds. The zkVM open-coding is not directly covered by host tests, but the algorithm is a well-known idiom.

Verdict: CORRECT

🤖 Generated with Claude Code