Bound pending findings during Report write failures

[JimBugwadia]

User outcome

API outages and noisy workloads cannot grow daemon memory without bound or starve other workloads.

Current behavior

Reporter.pending has no global budget. flush drains then requeues failed writes; distinct fingerprints continue to accumulate.

Scope

• Bound pending/in-flight/requeued findings together with deterministic overflow semantics.
• Preserve counts when merging retries; account for every dropped finding.
• Keep per-workload fairness and isolate transient from permanent failures.
• Verify the existing push sink and report-events flush consumers retain their documented behavior.

Acceptance

• Repeated API failure plus unique findings stays within a measured memory/entry budget.
• Retry merges and concurrent ingest never exceed the bound or double-count retained results.
• Recovery drains valid data; one noisy workload does not monopolize capacity.
• Drops are observable without exposing unsanitized fields.

Dependencies and boundaries

Child of #130. Coordinate permanent-size failures with #244; independently implementable.

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.