[BugFix] Fix nestloop join crash on const build/probe columns

[Wenjun7J]

Why I'm doing:

A BE crashes with SIGSEGV while running a nested-loop join. The PC is in
BinaryColumnBase<uint32>::append(const Column&, size_t, size_t) and the fault
address is near-null, e.g.:

*** SIGSEGV (@0x834) received ...
PC: starrocks::BinaryColumnBase<unsigned int>::append(...)
    starrocks::pipeline::NLJoinProbeOperator::_permute_probe_row(...)
    starrocks::pipeline::NLJoinProbeOperator::_permute_chunk_for_other_join(...)
    starrocks::pipeline::NLJoinProbeOperator::_pull_chunk_for_other_join(...)
    starrocks::pipeline::NLJoinProbeOperator::pull_chunk(...)

Root cause: the pipeline nestloop-join permute path
(NLJoinProbeOperator::_permute_probe_row / _permute_left_join) copies columns
through Column::append / append_value_multiple_times, which down_cast the
source to the concrete column type. In release builds down_cast is an unchecked
static_cast, so a ConstColumn that reaches the permute path is type-confused
as the destination column type (e.g. BinaryColumn). Its _offsets / _bytes
are then read from unrelated memory, producing a wild pointer and a SIGSEGV at a
near-null address.

This is reachable for degenerate nestloop plans where a constant inline view / CTE
feeds the build or probe side of a cross join (the equi-keys collapse to constant
predicate pushdown, so the join degrades to a nestloop join with a constant side).

The legacy non-pipeline CrossJoinNode guards every append with is_constant()
branches; the pipeline operator (introduced in #9430) never carried that protection
over, and there is no single chokepoint that guarantees const columns are
materialized before the join.

What I'm doing:

Materialize const columns at the nestloop-join build and probe entry points
(NLJoinBuildOperator::push_chunk and NLJoinProbeOperator::push_chunk) via
Chunk::unpack_and_duplicate_const_columns(), so the permute code never sees a
ConstColumn. This mirrors the existing convention added at the local exchange
source operator (#43403) for the same class of bug.

What type of PR is this:

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

Status

Warning

Draft. Pending validation on a build environment:

• BE build
• Reproduce the crash on the unfixed binary, confirm it is gone after the fix
• Add a regression test (SQL test for the degenerate constant-CTE nestloop plan)

Does this PR entail a change in behavior?

• No, this PR will not change any behavior. (Const columns are semantically
  identical to their materialized form.)

🤖 Generated with Claude Code