fix(rueidiscompat): set IsCacheHit for cached IntCmd and DurationCmd results

[NotAFlightRisk]

Running SCard and TTL twice each through compat.Cache(time.Minute) on v1.0.78, both still say IsCacheHit() is false the second time round, while Get on the same adapter flips to true. The replies really are coming strait out of the client-side cache (a plain DoCache of the same SCARD reports a hit), it's just the flag.

IntCmd never picked up the cache-hit line when #959 added it, so that's every cached call that returns one (StrLen, LLen, ZCard, BitCount and so on). DurationCmd and the JSONObjKeys path in SliceCmd do set it, but after an early return, which is why TTL only ever reported a hit for keys with no TTL.

With this the second SCard and TTL both come back as hits.

---

Note

Low Risk
Small metadata fix in command wrappers with regression tests; no change to Redis protocol, auth, or data semantics.

Overview
Fixes incorrect IsCacheHit() reporting on the go-redis compatibility layer when using client-side caching (compat.Cache / DoCache).

IntCmd now copies res.IsCacheHit() in from, so cached integer replies (e.g. SCard, StrLen, LLen, ZCard) report a hit on repeat calls. DurationCmd sets the flag on the positive-TTL early-return path so TTL and similar commands report hits when the cached value is > 0. SliceCmd sets the flag before returning on the JSON.OBJKEYS (json: true) path.

Adds TestCacheHitFromCachedResult to assert IntCmd, DurationCmd, and JSON SliceCmd return IsCacheHit() == true for cache-marshaled mock results.

^{Reviewed by Cursor Bugbot for commit 6514b2c. Bugbot is set up for automated code reviews on this repo. Configure here.}