Bound sealed execution result payloads

[mark-e-deyoung]

Why

The sealed public worker bounds incoming capsules, but a buggy or adversarial public-safe task could still write unbounded stdout/stderr or result files and consume runner disk/artifact storage.

Change

• bound captured stdout/stderr using deterministic truncation;
• bound substantive result file count, per-file size, and total retained result size;
• reject symlink/non-regular result entries;
• replace over-budget substantive results with a small bounded resource-exceeded record rather than upload a misleading partial result;
• preserve original task exit state in execution metadata;
• require the exact expected age recipient shape;
• add public contract tests for stream truncation, oversized result replacement, excessive file count, and recipient-shape rejection;
• preserve the seven-day encrypted-artifact pickup window.

Boundary

This is public execution-economics/reliability hardening, not a new project semantic or evaluator. It adds no scheduler, archive, private credential, public decryption key, private task identity, or trusted-side tracking coordinate.

Trusted-side dispatch/pickup/validation/reconciliation remains private and is intentionally not linked from this public PR.