fix(time-series): honour typeMapping for labels in RESP2 replies

[abhijeet117]

Summary

ts.mGetWithLabels, ts.mGetSelectedLabels and the two WITHLABELS ... GROUPBY range commands ignored typeMapping for the labels map on RESP2. Both transformers pass it to resp2MapToValue for the outer key map but call transformRESP2Labels / transformRESP2LabelsWithSources without it, although those helpers accept it. So with withTypeMapping({ [RESP_TYPES.MAP]: Map }) the outer container came back as a Map while labels stayed a plain object, diverging from RESP3 and from ts.mRangeSelectedLabels.

Testing

Reproduced via transformReply[2] with a synthetic RESP2 reply and { [RESP_TYPES.MAP]: Map }: labels was { label: 'value' } instead of Map(1) { 'label' => 'value' }. Added a regression test to each affected spec; both fail before the change and pass after. Type check and lint pass; replies without typeMapping are unchanged.

Checklist

• bug reproduced before fix
• root cause identified
• bug fixed
• tests pass

---

Note

Low Risk
Small reply-shape fix in time-series transformers; default object replies stay the same, only typeMapping users are affected.

Overview
RESP2 labels maps now respect typeMapping (e.g. Map) instead of always being plain objects.

createTransformMGetLabelsReply and the WITHLABELS GROUPBY transformer pass typeMapping into transformRESP2Labels / transformRESP2LabelsWithSources, matching the outer key map and RESP3. Default replies without a mapping are unchanged. Adds unit tests for TS.MGET WITHLABELS and TS.MRANGE WITHLABELS GROUPBY.

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

[PavelPashov]

@abhijeet117 Thanks for the PR. We’ll review it when we have capacity.