[BugFix] Fix scan-teardown use-after-free on MorselQueueFactory (backport #76259)

[mergify]

Why I'm doing:

CN/BE nodes crashed repeatedly with a use-after-free during query teardown.
The crash stack is consistently:

IndividualMorselQueueFactory::mark_split_source_morsel_finished
  <- ConnectorChunkSource::_report_split_source_morsel_finished_once
  <- ConnectorChunkSource::close
  <- ~ScanOperator <- ~PipelineDriver <- ~FragmentContext

FragmentContext destroys its members in reverse declaration order.
_morsel_queue_factories was declared after _pipelines, so it was
destroyed first. While _pipelines is then being torn down, a scan
operator's ConnectorChunkSource::close() (run from ~ScanOperator)
calls back into the MorselQueueFactory via
ScanOperatorFactory::mark_split_source_morsel_finished() — dereferencing
an already-freed object.

The callback in close() was added by #69095 as a safety net so
split-source completion is still reported when a chunk source exits
through non-EOF paths (cancel / error / limit reached). On those teardown
paths the factory is gone, so the report becomes a UAF. It only reproduces
for lake/connector scans that use split-source morsels and tear the
fragment down without reaching EOF.

What I'm doing:

Declare _morsel_queue_factories before _pipelines so it is destroyed
after the pipelines and their operators, matching the existing ordering
constraint already documented for _event_scheduler. This is a
member-declaration-order fix only; the relative order versus
_runtime_state / _plan is unchanged.

Add a regression test (FragmentContextExecRuntimeTest.MorselQueueFactoryOutlivesPipelines)
that installs a tracking MorselQueueFactory and a tracking Pipeline
into a FragmentContext and asserts the factory is still alive when the
pipeline is destroyed, pinning the destruction order so a future member
reshuffle cannot silently reintroduce the crash.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5

---

This is an automatic backport of pull request #76259 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of c613e0f has failed:

On branch mergify/bp/branch-4.1/pr-76259
Your branch is up to date with 'origin/branch-4.1'.

You are currently cherry-picking commit c613e0f971.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by us:   be/src/exec/runtime/fragment_context.h
	deleted by us:   be/test/exec/pipeline_fragment_context_exec_runtime_test.cpp

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr

[sevev]

Resolved the cherry-pick conflict manually.

The conflict was a modify/delete: on main a refactor moved FragmentContext
from be/src/exec/pipeline/fragment_context.h into be/src/exec/runtime/fragment_context.h
(the pipeline header became a compatibility shim) and introduced
be/test/exec/pipeline_fragment_context_exec_runtime_test.cpp. That refactor is
not in branch-4.1, so the cherry-picked paths do not exist here.

Adapted the fix to the pre-refactor 4.1 layout, preserving the original footprint:

• Applied the member-declaration-order fix (declare _morsel_queue_factories
  before _pipelines so it is destroyed after them) to the 4.1 location
  be/src/exec/pipeline/fragment_context.h.
• Recreated the regression test as a self-contained 4.1-native test
  be/test/exec/pipeline/fragment_context_morsel_uaf_test.cpp and registered it
  in be/test/CMakeLists.txt.

No behavior change; the fix is a member reorder. RUN CHECKER (BE build + UT)
will validate the ported test on 4.1.