[fix](load) Make insert cancellation reliable

[0AyanamiRei]

What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary:

INSERT INTO SELECT and CTAS expose two query cancellation races:

1. The insert coordinator is created before transaction initialization, but is published to StmtExecutor only after beginTransaction and sink finalization. A KILL QUERY, JDBC Statement.cancel(), or REST kill request received before publication finds the connection but no coordinator. The old path reports success and loses the cancellation, so the coordinator can later dispatch fragments and commit.
2. After coordinator.join() reports success, there is a window before onComplete() starts transaction commit. A cancellation in this window only targets an already completed coordinator, reports success, and does not prevent commit.

The same false-success behavior exists in local REST cancellation and follower-to-master forwarding because those layers do not propagate whether the statement accepted cancellation.

This PR:

• remembers cancellation in StmtExecutor and replays it when an INSERT or CTAS coordinator is published;
• checks coordinator cancellation while holding the dispatch lock before sending fragments to BEs;
• establishes a linearization point between cancellation and transaction commit: cancellation wins and aborts the transaction, or commit wins and the cancellation request is rejected;
• propagates the accepted or rejected result through ConnectContext, local schedulers, SQL KILL, JDBC cancellation, REST kill, Arrow Flight SQL, and forwarded FE cancellation;
• adds deterministic unit and regression coverage for cancellation before coordinator publication, cancellation before commit, and CTAS cancellation.

Scope: CANCEL LOAD is not changed by this PR. Running InsertLoadJob transaction/query binding is an independent load-job lifecycle issue.

Release note

KILL QUERY, JDBC Statement.cancel(), and the REST query kill API now reliably cancel Nereids INSERT INTO SELECT and CTAS before transaction commit, including coordinator-publication races. Cancellation attempted after commit begins returns an error instead of a false success.

Check List (For Author)

• Test

  • Regression test
    • ./run-regression-test.sh --run -d insert_p0 -s test_cancel_nereids_insert_query
  • Unit Test
    • ./run-fe-ut.sh --run org.apache.doris.qe.StmtExecutorTest
  • Manual test
    • Built FE with ./build.sh --fe -j48.
    • Verified the regression suite against FE version doris-0.0.0-1731787677f on query port 24030 and HTTP port 23030.

• Behavior changed:

  • Yes. Query cancellation is sticky until coordinator publication, cancellation is serialized against INSERT commit, and cancellation that arrives after commit begins returns failure.

• Does this need documentation?

  • No.

Check List (For Reviewer who merge this PR)

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

[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?