[fix](topn) fix AcceptNullPredicate adding back all null rows instead of only those in original bitmap

[zzzxl1993]

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Issue: AcceptNullPredicate::evaluate incorrectly adds back all NULL rows instead of only those in the original bitmap.

Root Cause: When multiple predicates are chained, the bitmap gets progressively filtered. The original code did bitmap |= null_bitmap after nested evaluation, which added back ALL NULL rows, including those already filtered out by previous predicates.

Example:

Original bitmap (after previous predicates): {0, 1, 2, 5, 6}
NULL rows in this column: {2, 3, 7}
Nested predicate result: {0, 1, 5}

Before fix: bitmap = {0, 1, 2, 3, 5, 7} ← Wrong! 3, 7 should not appear
After fix: bitmap = {0, 1, 2, 5} ← Correct! Only NULL row 2 added back
Fix: Capture bitmap & null_bitmap BEFORE nested evaluation, then add back only those NULL rows after.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[Thearas]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[zzzxl1993]

run buildall

[doris-robot]

TPC-H: Total hot run time: 31091 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit 3015bedd3edf3c04f3397574a962e697877597d1, data reload: false

------ Round 1 ----------------------------------
q1	17651	4407	4278	4278
q2	2020	378	229	229
q3	10117	1295	735	735
q4	10194	804	314	314
q5	7840	2219	1911	1911
q6	228	174	145	145
q7	880	725	608	608
q8	9275	1396	1052	1052
q9	5337	4844	4816	4816
q10	6893	1978	1568	1568
q11	524	293	303	293
q12	401	381	222	222
q13	17780	4080	3258	3258
q14	245	242	216	216
q15	921	827	804	804
q16	687	670	624	624
q17	650	763	562	562
q18	6911	6450	6499	6450
q19	1512	1007	632	632
q20	389	365	245	245
q21	2681	2034	1852	1852
q22	357	322	277	277
Total cold run time: 103493 ms
Total hot run time: 31091 ms

----- Round 2, with runtime_filter_mode=off -----
q1	4521	4348	4350	4348
q2	258	336	255	255
q3	2126	2610	2219	2219
q4	1375	1759	1323	1323
q5	4334	4238	4382	4238
q6	214	182	140	140
q7	1823	1810	1928	1810
q8	2708	2521	2514	2514
q9	7682	7557	7665	7557
q10	2907	3049	2664	2664
q11	576	499	455	455
q12	702	778	590	590
q13	3875	4429	3708	3708
q14	291	328	284	284
q15	891	805	811	805
q16	686	707	697	697
q17	1123	1490	1463	1463
q18	8385	7973	7735	7735
q19	910	908	860	860
q20	2104	2128	2012	2012
q21	4991	4290	4132	4132
q22	591	554	502	502
Total cold run time: 53073 ms
Total hot run time: 50311 ms

[doris-robot]

ClickBench: Total hot run time: 28.3 s

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit 3015bedd3edf3c04f3397574a962e697877597d1, data reload: false

query1	0.05	0.04	0.04
query2	0.10	0.05	0.05
query3	0.25	0.08	0.08
query4	1.61	0.10	0.10
query5	0.26	0.24	0.26
query6	1.17	0.70	0.68
query7	0.03	0.02	0.03
query8	0.05	0.04	0.04
query9	0.59	0.50	0.51
query10	0.54	0.55	0.55
query11	0.13	0.10	0.09
query12	0.15	0.10	0.10
query13	0.64	0.62	0.61
query14	1.06	1.05	1.06
query15	0.88	0.86	0.87
query16	0.41	0.39	0.40
query17	1.11	1.14	1.13
query18	0.22	0.22	0.21
query19	2.13	2.01	2.04
query20	0.02	0.01	0.02
query21	15.42	0.26	0.15
query22	5.08	0.06	0.05
query23	15.86	0.28	0.11
query24	1.57	0.29	0.19
query25	0.11	0.06	0.05
query26	0.15	0.13	0.13
query27	0.05	0.05	0.05
query28	3.96	1.15	0.97
query29	12.59	3.89	3.21
query30	0.28	0.14	0.12
query31	2.81	0.63	0.40
query32	3.25	0.59	0.51
query33	3.23	3.29	3.22
query34	16.13	5.38	4.76
query35	4.80	4.79	4.74
query36	0.66	0.50	0.50
query37	0.11	0.07	0.07
query38	0.07	0.04	0.04
query39	0.05	0.03	0.03
query40	0.20	0.17	0.15
query41	0.10	0.03	0.02
query42	0.04	0.04	0.04
query43	0.04	0.03	0.04
Total cold run time: 97.96 s
Total hot run time: 28.3 s

[hello-stephen]

BE UT Coverage Report

Increment line coverage 100.00% (4/4) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	52.59% (19385/36861)
Line Coverage	36.06% (180062/499280)
Region Coverage	32.44% (139635/430460)
Branch Coverage	33.43% (60454/180838)

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 100.00% (4/4) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	71.64% (25879/36124)
Line Coverage	54.28% (270360/498092)
Region Coverage	51.71% (224855/434878)
Branch Coverage	53.20% (96596/181570)

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 100.00% (4/4) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	71.64% (25880/36124)
Line Coverage	54.28% (270363/498092)
Region Coverage	51.71% (224876/434878)
Branch Coverage	53.20% (96603/181570)

[airborne12]

LGTM

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.

[HappenLee]

LGTM