Regression in 4.0.9: cache ID ignores date range, dimension and metric and the segfault error returns on cron with the ext-protobuf extension installed

How the cache ID regression came back in 4.0.9

1. Before 4.0.8, buildQuery() computed the cache ID as md5(serialize($parameters)). $parameters contains Protobuf objects (DateRange, Dimension, Metric), and calling PHP's serialize() on them crashes PHP with a segmentation fault when the ext-protobuf C extension is installed.

2. In 4.0.8, commit fbbecc0 ("clean boundary between Protobuf's complex object system and PHP's native...") fixed this by computing the cache ID from a separate $cache_params array of plain scalar values: property, start and end date, dimension, metric, offset and limit.

3. Meanwhile, the #3388151 dependency injection work lived on an issue branch that was started in 2023. Its commit 1c8500a was written in May 2024, before fbbecc0 existed, and it changed the same lines in buildQuery() (cacheTime() became cacheTime($configFactory)).

4. In October 2026, the branch was rebased onto 4.0.8. Replaying 1c8500a conflicted with the fbbecc0 version of the same lines. The conflict was resolved by keeping the branch's 2024 version, which silently dropped $cache_params and restored md5(serialize($parameters)).

5. The branch was then squashed into a single commit (da046fe) with a message about dependency injection, so the review didn't show that it also reverted an unrelated bug fix.

Result: since 4.0.9, every cron run segfaults on sites that have ext-protobuf installed (reproduced with ext-protobuf 4.33.6 on PHP 8.3 and 8.5). Sites without the extension aren't affected.

Note: the rest of fbbecc0 (caching a plain PHP array instead of the response object) was replaced on purpose in #3510521. That change now caches the response with Protobuf's own serializeToString() and mergeFromString(), which also works with ext-protobuf, so it's fine.

Tips for rebasing long-lived issue branches:
- When a rebase conflicts, compare against the current target branch. Check why those lines changed there (git log -L or git blame) before keeping the branch version.
- After rebasing, review the full diff against the target branch, not just the branch's own commits, to catch unrelated changes being reverted.
- Avoid squashing unrelated changes under one commit message, because it hides reverts from reviewers.