MSET p50 latency increased after dictFind key-length optimization

Describe the bug

I am seeing a repeatable MSET latency regression after the dictFind key-length optimization (1848809f #13792). The effect is not large, but it is consistent in my local runs. The clearest signal is p50 latency, which moves from about 1.48 ms to about 1.56 ms. Average latency and throughput also move in the slower direction. p95/p99 did not show the same regression in this particular run.

To reproduce

I compared the parent version with a version that includes 1848809f. The benchmark command was:

redis-benchmark -c 50 -P 10 -n 1000000 --csv \
  MSET test_MSET1 weiuvweiuvb \
       test_MSET2 4r4i3ih \
       test_MSET3 f348yg3gbeb \
       test_MSET4 23ry8342hfihbf \
       test_MGET4 wevgbewihviwe \
       test_MGET5 2f239fu439gfh4 \
       test_MGET6 23hr23ibf3jghi \
       test_MGET7 wbgvirhvorj \
       test_MGET8 pkwpjvkwnkv \
       test_MGET9 2qfnk23nfjb2gj4b \
       test_MGET10 24ty4inkwev

And the results was:

Metric	Before 1848809f	After 1848809f	Change
RPS	321234.97	315673.58	-1.73%
avg latency ms	1.49980	1.52680	+1.80%
p50 latency ms	1.47540	1.55780	+5.58%
p95 latency ms	2.42220	2.23460	-7.75%
p99 latency ms	2.59340	2.51780	-2.92%

Additional information

The benchmark repeatedly writes the same small set of string keys. Once those keys exist, the hot path should mostly be the lookup plus overwrite case:

MSET -> setKey() -> lookupKeyWrite() -> dbFind() -> dictFind()

As far as I understand the commit, dictFindByHash() can now use optional key-length callbacks, and dbDictType opts into that. That looks useful for avoiding repeated key-length work in some dictionary lookups.

For this particular short-key overwrite case, my guess is that the extra callback/branch path may be visible enough to affect the median. Does this look like an expected tradeoff of the optimization, or is there room to keep the benefit without paying that cost on small overwrite workloads?