[bug] GET /repos/:owner/:repo/installation returns stale installed=false for 60s after install webhook

[luciferlive112116]

Description

GET /api/v1/repos/:owner/:repo/installation (added in #203 for the registration UI install gate) is subject to the global CustomCacheInterceptor 60s production cache. When the GitHub App is installed and the installation / installation_repositories webhook sets repos.installation_id, repeated GETs with the same URL can still return installed: false until the cache entry expires.

GET /api/v1/health and GET /api/v1/pulls/:owner/:repo/:number/files already opt out via @NoCache(); the install-status endpoint does not.

Steps to Reproduce

1. Run the service with NODE_ENV=production and Redis configured.
2. Register a repo row without installation_id (or use a repo not yet installed).
3. Call GET /api/v1/repos/{owner}/{repo}/installation and note installed: false.
4. Install the Gittensor Mirror App on that repo so the webhook upserts installation_id.
5. Within 60 seconds, repeat the same GET with identical path/query.
6. Observe the cached pre-install payload (installed: false) is returned.

Expected Behavior

After the install webhook updates repos.installation_id, the install-status endpoint should reflect installed: true on the next read.

Actual Behavior

Cached GET responses can remain installed: false for up to 60 seconds after the webhook mutates the row.

Environment

• OS: Linux
• Runtime/Node version: Node 20

Additional Context

• packages/das/src/cache/custom-cache.interceptor.ts — caches all GET handlers unless @NoCache().
• packages/das/src/api/repos/repos.controller.ts — getInstallationStatus has no opt-out.
• Distinct from [bug] miners/dashboard/repos GET responses cached for 60s with no invalidation after webhooks #201 (miners/dashboard/maintainers stale scoring payloads); this endpoint gates repo registration before registered flips true.