Add fine control for workflow cache eviction

Is your feature request related to a problem? Please describe.

Some users want to control when workflows are evicted from the cache. For example:

• They may want to evict workflows they know will sleep for days. For non-latency-sensitive use cases, the cost of storing these workflows in the cache is higher than polling and replaying the workflow history when the timer fires. Ideally, they want to prioritize keeping in the cache workflows that they know are actively active and latency-sensitive.

• They may want to keep in cache workflows that will be queried after the workflow is closed (and evicted from cache). Querying closed workflows comes with extra latency since the workflow history has to be fetched and replayed by the worker before executing the query. Users want to control how long the workflow will be stored in the cache after the workflow is closed to prevent the extra latency that comes with fetch + replay

Describe the solution you'd like

Additional context

Per-SDK Tickets

• Go -
• Java -
• Core -
• TypeScript -
• Python -
• .NET -
• Ruby -
• PHP -
• Temporal CLI -

The issue names no files, tests, or implementation entry points; begin by clarifying the cache-eviction design across Core and the listed SDKs. Define the intended controls for open and closed workflows, then use the per-SDK checklist to establish which integrations and tests are required before the feature is complete.