Handle split nodes as regular nodes if range vector splitting is disabled on queriers

[fionaliao]

What this PR does

For range vector splitting to work, it has to be enabled both on the query-frontend (for planning) and the queriers (for the actual execution of the splitting). Currently, if it is enabled on the query-frontend but disabled on the queriers, an error will be returned. To avoid errors, you'd have to enable on the queriers first and then on the query-frontend.

To make enabling query splitting less manual without errors one rollout, this PR changes the split node materializer logic to just materialize the original node if splitting is disabled.

Which issue(s) this PR fixes or relates to

Follow up to #13472

Checklist

• Tests updated.
• Documentation added.
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]. If changelog entry is not needed, please add the changelog-not-needed label to the PR.
• about-versioning.md updated with experimental features.

---

Note

Low Risk
Changes split range-vector execution to degrade gracefully (with a warning) instead of failing when queriers have splitting disabled, reducing rollout risk but slightly altering behavior in a misconfigured setup.

Overview
Prevents query failures when a SplitFunctionCall node arrives at a querier with RangeVectorSplitting disabled by materializing and executing the wrapped FunctionCall normally (and logging a warning) instead of returning an error.

Refactors the split materializer registration to always use rangevectorsplitting.NewMaterializer(enabled, cache, logger), removes the generic DisabledMaterializer, and updates/extends tests to cover the query-frontend-enabled/querier-disabled fallback case.

^{Written by Cursor Bugbot for commit abebc3f. This will update automatically on new commits. Configure here.}