Use the existing RingBuffer for keeper executions

[shaurya703]

Fixes #808.

last_executions is now the RingBuffer already used by state.failures, so the two bounded-history lists in this file use one implementation instead of two — and eviction is pop_front rather than Vec::remove(0) shifting every remaining element.

Cap stays 100, the admin endpoint still returns the most recent 50. Behaviour unchanged.

Three things the swap needed, none of them obvious from the issue

• Default is now hand-written. RingBuffer::default() is FAILURE_RING_CAPACITY — the failures list's 256. Keeping the derived Default would have silently grown this list from 100 to 256 with nothing to notice. There is a test that fails if it ever goes back.
• RingBuffer gained a Serialize impl, because KeeperStatus derives Serialize and this field is part of it. Oldest-first, matching the Vec, so anything serializing a struct that holds one sees the same array as before. (KeeperStatus is not serialized anywhere today — KeeperStatusResponse is, and builds its own Vec — but the derive is there and I did not want to remove it as a side effect of a performance change.)
• The admin handler iterates and clones instead of consuming: RingBuffer exposes iter(), not into_iter().

Tests

Two, both in state.rs:

• The eviction bound itself — push capacity + 25, assert exactly 100 remain, oldest evicted, newest retained, order preserved. Nothing covered this before, so a capacity change would have gone unnoticed.
• A guard on the Default trap above.

Verified non-vacuous: switching Default back to RingBuffer::default() fails both (292 passed; 2 failed).

Checks

cargo test — 16 suites green, 294 lib tests. cargo fmt --check clean. cargo clippy --all-targets -- -D warnings clean.