Interface Kernel

Bulk transforms used on the encoder's fast path.

Every method writes into out starting at pos and returns the position just past the last byte written.

out.length is the bound, and the only one. The two packers are handed a region the caller has already sized exactly (4 or 8 bytes an element, a number the caller can compute), so for them "enough room" is a guarantee. The two varint kernels are not: a varint's length depends on the value, so the caller cannot know the size without encoding it, and asking the source how wide its elements are is exactly the guess that silently truncated messages (§5.1). So a varint kernel must

• never write at or past out.length, and
• keep counting anyway, returning the position it would have reached.

The caller compares that against out.length: past the end means the message does not fit, which in the block mode is BUFFER_FULL — the answer that mode exists to give. The JS kernel satisfies this for free (a typed-array store past the end is dropped while pos keeps advancing); a native or WebAssembly kernel must implement it deliberately, counting the remaining elements without storing. Headers, counts and flushing stay in the stream classes; a kernel only moves bytes — with one obligation it cannot delegate, because it is the only code that ever looks at the elements: the integer kernels must reject an element outside the 64-bit value domain (CORELIB_PLAN §6.2 — `0 .. 2^64

• 1unsigned,-2^63 .. 2^63 - 1signed) by throwingargumentError, rather than reducing it modulo 2^64. The stream classes range-check the same values on their element-at-a-time streaming path, so a kernel that skipped the check would make the wire depend on which constructor the caller used (#106). The check is one store, one load and one compare on the bigint branch (splitU64/splitI64); the number` fast paths are already gated on the domain and pay nothing.