fix: unbounded pending queue + non-idempotent iptables rules

[imran-siddique]

Summary

Several unbounded data structures and non-idempotent operations could lead to resource exhaustion:

1. Pending approvals queue unbounded (blocklist.rs:56) — pending_approvals: Vec has no size limit. A noisy agent spamming egress fetch with random URLs could exhaust router memory.

2. iptables rules not idempotent (entrypoint.sh:44-65, reconciler.rs:666-700) — rules are appended without checking for duplicates. Pod restarts accumulate duplicate rules, degrading network performance.

Proposed Fixes

Bounded queue:

const MAX_PENDING: usize = 1000;
if pending.len() >= MAX_PENDING {
    return Err("Pending approval queue full");
}

Idempotent iptables:

# In egress-guard init container:
iptables -F OUTPUT 2>/dev/null || true  # Flush existing rules
iptables -A OUTPUT ...                   # Apply fresh

AGT's resource quota policy engine can enforce configurable limits on all bounded resources.

References

• blocklist.rs line 56
• entrypoint.sh lines 44-65
• reconciler.rs lines 666-700

[pallakatos]

Resolved in main (merge commit 8f90e58)

Pending approval queue capped at 1000 entries. iptables rules use flush-before-append for idempotency.

Implementation:

inference-router/src/blocklist.rs lines 56–61:

const MAX_PENDING: usize = 1000;
// Enforced at lines 366, 436:
if !already_pending && pending.len() < MAX_PENDING { ... }

sandbox-images/openclaw/entrypoint.sh lines 50–51:

iptables -N AZURECLAW_EGRESS 2>/dev/null || iptables -F AZURECLAW_EGRESS

Prevents OOM from unbounded queue growth. iptables chain is flushed before append to avoid duplicate rules on container restart.

Key commit: 7e569af (Phase 3: queue cap + iptables flush)