Create new block when filter OrdinalBytesRefBlock

[dnhatn]

Currently, when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector, we reuse the existing dictionary and filter only the ordinals. Although this is semantically correct, it can break HashAggregationOperator when ordinal optimizations are enabled in BlockHash.

Example:
Given an incoming OrdinalBytesRefBlock after filtering:

dict: [apple, banana, orange]
ordinals: [0, 0, 0, 0, 1, 1]

Here, orange is not referenced. During grouping and hashing, all dictionary entries [apple, banana, orange] are hashed with group IDs [1, 2, 3] (0 reserved for null), and the block produces groupings [1, 1, 1, 1, 2, 2]. The output is correct, but when evaluating partial/final results, we cannot exclude orange (groupId=3) unless we enter slow mode and track every seen group. This can cause an IndexOutOfBoundsException if orange is the largest group and the over-allocation is not enough to cover it, or orange may be included in the result even though it was excluded previously.

This change enforces the creation of a new Block/Vector when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector.

Closes #136423

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Hi @dnhatn, I've created a changelog YAML for you.

[dnhatn]

Without the fix, Purchase Manager would re-appear in the result.

employees:long | job_positions:keyword
18             | Accountant
13             | Architect
11             | Business Analyst
13             | Data Scientist
10             | Head Human Resources
15             | Internship
14             | Junior Developer
20             | Principal Support Engineer
0              | Purchase Manager
13             | Python Developer
15             | Reporting Analyst
20             | Senior Python Developer
15             | Senior Team Lead
11             | Support Engineer
15             | Tech Lead