…hint The `to_the_end` scanner reads a whole source into one message with io.ReadAll, which receives no size hint. In Go 1.26 io.ReadAll builds a list of exponentially growing chunks and then copies them into a single right-sized slice, so at peak the chunks and the final copy are live simultaneously and it holds roughly twice the content size in memory. For the `file` input this is avoidable: it already calls Stat() on every file (for the mod time) and so already knows the exact size, but never used it. This threads an optional SizeHint through SourceDetails so the `file` input can hand the scanner the size it already has, and replaces io.ReadAll in the to_the_end scanner with a capacity-hinted read that allocates the buffer once up front. The hint is an optimisation only and never a correctness input: if the file grows past the hint the buffer still grows exactly as before, and if it shrinks the read ends early, so the bytes returned are identical to io.ReadAll for any hint value. A previously latent defect is fixed as part of the plumbing: codec/scanner.go reconstructed the details object and copied only Name, silently dropping any other field. It now propagates SizeHint too (and nil-guards details). Measured on a 64 MiB in-process benchmark (Go 1.26.6, benchstat n=6): bytes allocated 157.7Mi -> 64.0Mi -59.4% (p=0.002) allocations 36 -> 2 -94.4% (p=0.002) In plain terms: to read a 64 MiB file the scanner previously reserved about 158 MiB of memory -- roughly two and a half times the file -- and did so in 36 separate allocation steps. It now reserves about 64 MiB (the file size itself) in a single step. So peak memory for the read drops from ~2.5x the file size to ~1x. For customers this is the difference that can keep large-file pipelines within a memory limit instead of being OOM-killed; the effect grows with file size (a multi-GB file previously peaked at two to three times its size in RAM). Nothing about the output or configuration changes -- it is purely a reduction in memory used. The p=0.002 figures mean the improvement is statistically solid, not measurement noise. make fmt, make lint and make test all pass.

Follow-ups from review of the size hint work: - readAllHinted delegates to io.ReadAll when there's no usable hint — growing from an empty buffer was measurably worse than stdlib's strategy for every unhinted source (~2.4x the bytes allocated on a 64 MiB read), and unhinted sources are the common case. - Pre-allocation from a hint is capped at 1 GiB, so a wildly wrong size (procfs oddities, a custom filesystem returning garbage) can't turn into an enormous up-front allocation or a makeslice panic (hint+1 overflows at MaxInt64). Content beyond the cap still reads fine. - The decompress scanner strips the hint before handing details to its child, since it describes the compressed stream rather than the one the child actually reads. - codecRPublic passes details through wholesale instead of copying field by field, so future fields can't be silently dropped again. - ScannerSourceDetails getters are safe on a nil receiver now (details are optional everywhere), which lets the scattered nil guards go. - Docs spell out that a zero hint is indistinguishable from unset; the file input's Stat failure log includes the error value; copyright years bumped on touched files. Tests: huge-hint clamp coverage, an unhinted-path benchmark, decompress hint-strip coverage, and nil-receiver getter coverage.

Follow-ups from a second review pass over the branch: - readAllHinted copies the result down when a hint overestimated the content (source truncated between Stat and read, or a misreporting filesystem), so the returned message no longer pins the whole pre-allocated array for its lifetime. An accurate hint leaves cap at len+1 and never pays the copy. - The SizeHint contract docs now state the wrapping-scanner invariant that decompress previously enforced only as inline code: a wrapper that transforms stream length must clear the hint before forwarding details. Setter docs also note they panic on a nil receiver, unlike the getters. - The capture-scanner test scaffolding duplicated between the file input and decompress scanner tests is consolidated into internal/component/scanner/testutil, with the capture callbacks now consistently mutex-guarded.

Third pass from review, tightening the memory behaviour of the hinted read and reconciling the contract docs with the in-tree wrappers: - The pre-allocation clamp drops from 1 GiB to 128 MiB: large enough that typical whole-stream messages keep the single-allocation benefit, small enough that a bogus Stat can't spike a constrained deployment before a byte is read. - Growth past the hint (source grew after being measured, or content beyond the clamp) now doubles explicitly instead of relying on append's ~1.25x strategy, keeping cumulative allocation linear in the content size much like io.ReadAll's chunking, with the same +1 trick so content ending exactly at a doubled capacity doesn't force one more doubling just to observe EOF. - The pre-allocation is floored at io.ReadAll's 512-byte starting size, so a tiny stale hint doesn't begin with pathologically small reads. - The copy-down of excess capacity now only runs on success (the caller discards the buffer on error) and only when the waste exceeds 64 KiB, where it's worth the copy. - The file input ignores negative Stat sizes from misbehaving custom filesystems, keeping the documented zero-means-unknown contract. - The SizeHint contract now distinguishes wrappers that materially transform stream length (decompress: must clear the hint) from those trimming a bounded few bytes (skip_bom: may forward it, and now says so at the forwarding site). - The details-capture test scanner owns its synchronised state and returns an accessor, rather than each test hand-rolling globals. - Changelog notes the 128 MiB cap and that deprecated string codec configs are unaffected.