chore(foundation): faster toBufferBE via zero fast-path

[fcarreiro]

Summary

Adds a zero fast-path to toBufferBE, the bigint→big-endian-buffer conversion underlying Fr.toBuffer(). Field elements serialized in protocol structs are overwhelmingly zero (kernel public inputs are mostly fixed-size zero-padding), so short-circuiting the zero case avoids a wasteful bigint → hex string → Buffer.from(hex) round-trip.

if (num === 0n) {
  return Buffer.alloc(width);
}

Why

Profiling Tx.toBuffer() showed it spends ~6.7ms almost entirely in per-field Fr.toBuffer() across ~3900 fields, and 96% of those fields are zero. The scalar conversion is already near-optimal otherwise — a 64-bit-words variant (writeBigUInt64BE×4) is actually slower on real (non-zero) field elements because V8's bigint shifts allocate.

Micro-benchmark of toBufferBE variants (width=32, correctness-checked against current):

variant	96%-zero (real)	all-random (worst case)
current	452 ns	382 ns
64-bit words	215 ns	503 ns (slower)
zero fast-path	55 ns	387 ns (free)

The fast-path is ~8× on the real workload and costs one === 0n compare on the worst case.

Impact

End-to-end on mockTx(42):

	before	after
tx.toBuffer() total	6.66 ms	4.20 ms (−37%)
data.toBuffer()	4.34 ms	2.25 ms (−48%)

data.toBuffer() (the kernel public inputs) is the production-relevant figure: the mock serializes an uncompressed proof, whereas real txs carry a compressed proof that serializes as a single blob. The benefit applies to every Fr.toBuffer() / serialization path in the monorepo, not just txs.

The remaining cost is structural — a Buffer is allocated per field and then Buffer.concat'd across thousands of them. Eliminating that needs a single-preallocated-buffer serializer; this change is the safe, broadly-beneficial first step.

Testing

toBufferBE previously had no direct unit tests; added coverage for the zero path, big-endian left-padding, exact-width values, and the negative-input throw. The conversion is otherwise byte-identical to before.