Invalidate repository-detail cache when repository activity advances

[jskoiz]

Verified against main at 715c52e.

Impact

Repository detail entries are considered fresh solely from refreshedAt < 24 hours. The cache already records an activityAt value derived from the repository's latest pushedAt / updatedAt, but the read path never compares the cached marker with the current repository marker.

As a result, a push or newly updated pull request can be visible in the repository list while the cached latest commit/detail remains stale for up to a day. refresh=1 bypasses the five-minute dashboard cache but still reuses the one-day detail entry, so the user-visible Refresh action cannot correct it.

Concrete code references

• The cache entry stores both refreshedAt and activityAt.
• Freshness checks only elapsed time, then returns the cached details immediately.
• The current activity marker is available and persisted after a refresh.
• Activity is derived from pushedAt and updatedAt.

Acceptance criteria

• A repository inside the scan set is revalidated when its current activity marker advances beyond the marker stored with a still-within-TTL cache entry.
• A full/forced dashboard load returns the updated surviving detail fields after such activity without requiring the 24-hour TTL to expire.
• Unchanged repositories continue to use the bounded one-day cache; this change must not turn Refresh into an unconditional all-repository fan-out.
• A failed revalidation preserves the last known value for the failed field, emits the existing sanitized partial-data warning, and remains eligible for retry.
• Existing out-of-scan warnings and hosted-vs-local cache boundaries remain intact.

Test expectations

• Add a fake-time server test that seeds detail cache, advances repository pushed_at or updated_at within 24 hours, and proves the relevant upstream detail call and new payload value occur.
• Add the inverse assertion that an unchanged activity marker performs no extra detail call.
• Cover partial refresh failure and retained prior data.
• Run npm run test -- --project server and npm run check.

Dependencies / order

Implement after the public fan-out issue. If that issue removes latestPullRequest, apply activity invalidation only to the detail fields that remain in the final contract.

Non-goals

• Forcing every scanned repository to refresh on every button press.
• Removing the 24-hour cache or widening scanLimit.
• Refreshing repositories outside the bounded scan set.
• Adding a distributed cache.