Bound serialized Report size before Kubernetes API writes

[JimBugwadia]

User outcome

A workload generating large findings cannot permanently wedge its Report with oversized writes.

Current behavior

Reporter caps result count at 500, not serialized bytes. Report metadata and multibyte properties also consume the API request budget. Per-pod ownership does not solve object size.

Scope

• Enforce a conservative serialized-byte budget including metadata and configuration.
• Define deterministic retention/truncation and a visible loss counter.
• Handle a single over-budget result without a permanent retry loop; preserve sanitize/redaction.

Acceptance

• Worst-case multibyte findings and large metadata remain inside the configured budget.
• An oversized result cannot prevent later valid findings from being written.
• Transient errors remain retryable; permanently oversized writes are not endlessly retried.
• Kind validation proves accepted Report writes under a high-cardinality workload.

Dependencies and boundaries

Child of #130; coordinate with the pending-buffer bound. No new aggregator or transport is required.

Validation and completion

• Table-driven tests pin the stated invariant, including invalid input and policy updates.
• For code changes: make build and make test; significant changes also require make kind-install and a targeted behavioral check. Pipeline, collector, evaluator, or reporter changes require make smoke-quickstart.
• Kernel changes use the pinned BPF builder, generated-artifact verification, verifier loading, and allowed/denied behavior tests on supported hook paths.
• Update DESIGN, development guidance where affected, and the RuntimePolicy reference and limits. Every rejected user rule must reach an operator log and policy condition; count every observation drop. Preserve the reporter redaction boundary.