fix(hooks): bound OCI hook stdout/stderr capture to avoid OOM

[Atishyy27]

Problem

Closes #797.

executeHook captures a hook's stdout and stderr into plain bytes.Buffer values:

var stdout, stderr bytes.Buffer
...
cmd.Stdout = &stdout
cmd.Stderr = &stderr

bytes.Buffer grows to hold everything written to it. A prestart/poststart/etc. hook that emits a large amount of data — by accident or malice — is buffered entirely in memory even though the output is only ever used to build an error string. That is an unbounded allocation and a potential OOM.

Fix

Introduce limitedBuffer, an io.Writer that keeps at most maxHookOutput (1 MiB) per stream and discards the rest, flagging the result as truncated:

• Retains the first maxHookOutput bytes, appends ... [output truncated] when it drops data.
• Always returns len(p), nil from Write, so exec's internal io.Copy never fails with ErrShortWrite and the hook process is neither blocked nor killed with EPIPE.

Tests

TestLimitedBufferCapsOutput covers: under-limit (kept verbatim), exact-limit (not marked truncated), a single oversized write (capped, full length still reported), and a flood of writes (stays bounded at the cap).

Verification

go build, go vet and test compilation pass (cross-compiled to linux/amd64); the limitedBuffer behaviour was also run directly (oversized write → n reported = 10, retained = 4; 10 KB flood → retained = 5 with full length reported). CI runs the full suite on Linux.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	ad792be
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/6a4f48ec31c77b00072d4274

[cmainas]

Hello @Atishyy27 ,

please read the contribution guide.