ADR-011 History is kept by time, whatever the API server compacts

How it is kept changed with ADR-014; what is kept did not.

The API server compacts etcd every five minutes, and etcd then throws the older versions away. QuantyKube honors compaction toward etcd clients exactly: a read or a watch below the compacted revision fails with etcd's own error, so nothing in Kubernetes sees different behavior. What is physically kept is decided separately, by --retain, one hour by default. Within that window every commit and every log entry stays. A gRPC service of QuantyKube's own on the same socket serves it (docs/HISTORY.md), and quantykube history, get and restore use that service: list what happened to a key, read it as it was at a revision or a time, and write it back. A restore is an ordinary write, so the API server's watch cache sees the object return.

Once a minute the server drops what is older than the window: log entries first, in a commit, then QuantyDB's collector frees the pages. It never drops a revision at or after the compaction point, whatever the window, because etcd clients may still read those.

The cost: disk. Copy on write means every commit writes new pages for the path it touched, and keeping an hour of commits keeps all of those pages. The benchmarks will say how much that is under a real API server before the default is defended in public. A restore brings back the value, not the lease, so an object that had a lease comes back without one.