Bound Azure Pipelines selector history and publish cost

从 src/AzurePipelines/PipelineCachingCacheClient.cs 中的 GetSelectors(...).ToHashSetAsync 以及关于限制存储的 selector 数量的 TODO 开始。跟踪带时间戳的 selector key、manifest 和路径集下载的处理方式，然后为 selector 变化、去重、驱逐、有界的 manifest 大小以及远程请求添加测试。完成的标准是：保留和发布工作仍保持有界，同时保留的 selector 仍能提供预期的缓存命中。

Summary

The Azure Pipelines cache backend carries forward every selector ever observed for a weak fingerprint and republishes the complete set on each new selector.

Impact

For a recurring weak fingerprint whose path set or strong selector changes over time, each miss fetches the prior selector manifest, downloads every unique historical path set, writes temporary files, and republishes the full set. Publish work grows linearly with selector history rather than remaining bounded. Azure retention and selector deduplication limit some scenarios, but a long-lived cache universe can still accumulate substantial sequential remote I/O.

Evidence

src/AzurePipelines/PipelineCachingCacheClient.cs calls GetSelectors(...).ToHashSetAsync, adds the current selector, then iterates all selectors and republishes them. The implementation already contains TODO: limit the number of selectors we store. Timestamped selector keys carry the newest set across builds.

Suggested fix

Introduce a bounded retention policy for selectors per weak fingerprint, preserving the most useful/recent entries. Avoid downloading historical path-set content that will not be retained. Add instrumentation or tests demonstrating bounded manifest size and remote requests.

Acceptance criteria

• Selector count and manifest size remain bounded under repeated selector churn.
• Existing selectors still provide expected cache hits within the retention policy.
• Publishing a new selector performs bounded remote work.
• Tests cover churn, deduplication, and eviction behavior.