feat: add Redis caching for bounty listings (#128)

[TeapoyY]

Description

Fixes issue #128: Redis caching for the bounty listings.

Added Redis caching to the GET /api/bounties endpoint to improve performance for frequently-accessed bounty listings.

Changes

New dependency

• Added ioredis ^5.6.1 to @devasign/api package

New service: packages/api/src/services/redis.ts

• getRedisClient() - Lazy singleton Redis client using REDIS_URL env var
• getCached<T>(key) - Get and parse JSON from Redis, returns null if Redis unavailable
• setCache(key, value, ttlSeconds) - Set a JSON value with TTL
• deleteCachePattern(pattern) - Scan and delete all keys matching a pattern (non-blocking)

Cache implementation in GET /api/bounties

• Cache key is built deterministically from query params (tech_stack, amount_min, amount_max, difficulty, status, limit)
• First page (no cursor) results are cached for 30 seconds (BOUNTY_LIST_CACHE_TTL)
• Subsequent pages (with cursor) are not cached to keep pagination consistent
• Cache is automatically invalidated when a bounty is updated or completed

Cache invalidation

• PATCH /api/bounties/:id - Invalidates all bounty:list:* keys
• POST /api/bounties/:id/complete - Invalidates all bounty:list:* keys

Testing

1. Start Redis via docker-compose up redis
2. Ensure REDIS_URL=redis://localhost:6379 in .env
3. Request GET /api/bounties - first request hits DB, second request should be served from Redis cache
4. Update a bounty - next listing request should hit DB again (cache invalidated)

Closes #128

[devasign-agent]

The PR introduces a solid reusable Redis service with safe get/set/pattern-delete operations and adds caching to the bounty listing endpoint. However, several criteria are not met: the listing TTL is 30 seconds instead of the required 5 minutes, the recommendations endpoint has no caching at all (15 min TTL missing), and there is no cache invalidation tied to tech stack updates. Status-change invalidation is partially handled via PATCH and complete endpoints, but other status transitions (e.g., applications/assignment flows) may not invalidate.

[devasign-agent]

End goal

Add Redis caching to the bounty listing and recommendation endpoints with appropriate TTLs and invalidation on relevant data changes.

❌ Acceptance criteria not met

• C1 — Redis caching is added to the bounty listing endpoint (GET /api/bounties) with a 5-minute TTL.
• C2 — Redis caching is added to the recommendations endpoint with a 15-minute TTL.
• C3 — Cached entries are invalidated when a bounty's status changes (e.g., bounty update and completion).
• C4 — Cached entries are invalidated when tech stack updates occur.
• C5 — A Redis service/client is implemented with get, set (with TTL), and delete/invalidation capabilities, configured via the REDIS_URL environment variable.
• C6 — Caching degrades gracefully (e.g., returns null or falls back to DB) when Redis is unavailable.
• C7 — Cache keys are built deterministically from the relevant query parameters so distinct queries produce distinct cache entries.

---

📋 One prompt to fix all of this — paste into your AI coding agent

You are helping fix PR "feat: add Redis caching for bounty listings (#128)" in devasignhq/mobile-app. Automated review flagged the items below as blocking approval. Apply the changes so each one passes — don't introduce changes beyond what's listed.

## End goal
Add Redis caching to the bounty listing and recommendation endpoints with appropriate TTLs and invalidation on relevant data changes.

## Failed acceptance criteria

### 1. Redis caching is added to the bounty listing endpoint (GET /api/bounties) with a 5-minute TTL. (C1)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

### 2. Redis caching is added to the recommendations endpoint with a 15-minute TTL. (C2)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

### 3. Cached entries are invalidated when a bounty's status changes (e.g., bounty update and completion). (C3)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

### 4. Cached entries are invalidated when tech stack updates occur. (C4)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

### 5. A Redis service/client is implemented with get, set (with TTL), and delete/invalidation capabilities, configured via the REDIS_URL environment variable. (C5)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

### 6. Caching degrades gracefully (e.g., returns null or falls back to DB) when Redis is unavailable. (C6)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

### 7. Cache keys are built deterministically from the relevant query parameters so distinct queries produce distinct cache entries. (C7)

_(No specific patch was suggested for this criterion — use the criterion text and evidence above to plan the fix.)_

## Your task
For each failed criterion and blocker above, apply the suggested fix. Use the `Relevant diff` hunks as the anchor for where to make the change. After each change, re-verify it satisfies the criterion or addresses the blocker it's tied to.