[fix](be) remove duplicate default argument on clear_blocks forward declaration

[damokelis]

What problem does this PR solve?

Under Unity Build, be/src/exec/sink/writer/async_result_writer.cpp fails to compile:

error: redeclaration of `clear_blocks` may not have default arguments

clear_blocks<T>() is declared twice with the same default argument for memory_used_counter:

• be/src/exec/exchange/local_exchanger.h:27-28 — the original declaration, = nullptr
• be/src/exec/sink/writer/async_result_writer.cpp:316-317 — a forward declaration added by [opt](build) 1/4: Speed up BE full build ~22% by cutting hot-header include edges #66400 (opt 1/4: Speed up BE full build ~22% by cutting hot-header include edges) to avoid pulling in local_exchanger.h, also = nullptr

C++ forbids repeating a default argument across declarations of the same function template ([dcl.fct.default]/4). Separate translation units never see both, so a normal build is fine — but Unity Build concatenates sources into one TU, both declarations land together, and -Werror turns it into a hard error.

Fix

Drop the default from the forward declaration in async_result_writer.cpp. The one in local_exchanger.h still applies at every call site that sees that header, so no call site changes.

Release note

None

Check List

• Test

  • No need to test or manual test. Explain why:
    • Compile-only fix; no behavior change. The removed token is a default argument on a declaration, and every existing call site passes the argument explicitly or sees the header-declared default.

• Behavior changed:

  • No.

• Does this need documentation?

  • No.

[hello-stephen]

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?