Invalidate Redis tag keys concurrently with bounded fan-out

[groupthinking]

Run per-tag smembers/delete invalidations concurrently in RedisCacheLayer.invalidate_by_tags, bounded by the shared tag-write semaphore to stop latency growth.

[linear-code]

GRV-257

[github-actions]

👋 Thanks for opening this issue! It has been automatically labeled for triage.

[coderabbitai]

🔗 Related PRs

#1152 - perf: issue Redis tag-set writes concurrently on cache set [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[groupthinking]

Resolved on `main` by #1262 (merged) — closing as triage hygiene.

Verified in current `origin/main`, `src/youtube_extension/backend/services/intelligent_cache.py:506` (`invalidate_by_tags`):

• Per-tag `smembers`/`delete` pairs now run concurrently via `asyncio.gather` instead of sequentially.
• Fan-out is bounded by `_get_tag_write_semaphore()`, with one permit held across the whole `smembers`->`delete` pair so each tag stays a single causally-ordered unit and cannot be left half-invalidated.
• `gather(..., return_exceptions=True)` prevents a failing tag from leaving sibling tasks in flight that would touch `conn` after the enclosing `async with` closed it; the first exception is re-raised so the existing error path still reports 0.

The rationale is documented inline, including the correction that holding the permit across the pair is about scheduling determinism rather than reducing peak pool-connection usage (redis.asyncio returns the connection to the pool between awaits).