Apollo Client InMemoryCache serving stale results under default cache-first policy

Apollo Client's InMemoryCache uses a cache-first fetch policy by default: when a query already has cached results, reads are served from the normalized store without contacting the server. The cache has no built-in time-to-live, so entries persist indefinitely until a mutation writes new data, refetchQueries runs, or entries are evicted.

The goal is to keep query results acceptably fresh for data that can change on the server independently of any client-side mutation, without pushing every read onto the network. Candidate mechanisms include the cache-and-network policy, refetchQueries on selected mutations, cache.evict followed by cache.gc, and pollInterval, but it is unclear how their freshness guarantees and request costs compare in Apollo Client 3.x.

Specific questions:

• Is there a supported way to bound the age of cache-first results, such as a TTL or staleness threshold, in Apollo Client 3.x?
• For server-side changes the client cannot observe, how do refetchQueries, cache eviction, and pollInterval compare as freshness strategies?
• Does cache-first ever revalidate in the background, or does it reach the network only on a cache miss?