refactor(sync): use deque(maxlen=N) for pending attestation buffers

[tcoratger]

Summary

Both pending attestation queues in SyncService previously appended into a list and then sliced back to MAX_PENDING_ATTESTATIONS whenever the size exceeded the cap. Switching to collections.deque(maxlen=N) lets the standard library do the bookkeeping: each append drops the oldest entry atomically when the deque is full, so the buffer never exceeds the cap even momentarily.

Behaviour

Identical: drop-oldest, keep-newest, insertion order preserved.

• Before: buffer at MAX → append(new) grows to MAX+1 → slice [-MAX:] drops index 0.
• After: buffer at MAX → append(new) atomically drops index 0 and pushes new on the right.

Same items kept, same items dropped, same final ordering.

Replay drain

pending = self._pending; self._pending = [] would have replaced the deque with a plain list. Switched to pending = list(self._pending); self._pending.clear() so the field stays a deque after the drain. Failed retries re-append into the empty deque just like before.

Tests

Five equality assertions wrap the deque in list(...) because deque == list is False in Python. The trim-bound tests (test_pending_attestations_trimmed_to_max, test_pending_aggregated_trimmed_to_max) — which feed MAX + 50 items and assert the final length is exactly MAX with the last item being the newest — pass without modification.

Test plan

• ruff check — clean.
• uv run pytest tests/lean_spec/subspecs/sync/test_service.py — 34 tests pass.

🤖 Generated with Claude Code