ETag transport cache grows unbounded in long-running spawner

What happened?

The etagTransport introduced in #682 caches every unique GET URL (including paginated URLs like ?page=2&per_page=100) for the lifetime of the process. In a long-running taskspawner-loop controller, this map grows without bound and leaks memory over days/weeks.

What did you expect to happen?

The cache should have a bounded size or TTL-based eviction so memory usage stays stable in long-running deployments.

Possible approaches

• Cap the cache at a fixed number of entries (e.g., 1000) with simple LRU eviction
• Add a TTL per entry (e.g., 10 minutes) so stale entries are reaped
• Both — LRU + TTL

Additional context

In the typical single-repo case, the number of unique URLs per cycle is small (issues list pages + comment pages), so this is low-urgency. It becomes more relevant if a spawner targets a high-volume repo with many paginated comment threads.

Introduced in #682.

/kind cleanup

Start with the etagTransport implementation introduced in issue #682 and trace how the taskspawner-loop creates and reuses it across requests. Compare the cache lifetime with the loop lifetime, then define and verify an eviction policy that keeps memory bounded during long-running, paginated workloads.