feat(workflow-operator): export the samplers, Split and the control-flow operators as Python - #8710

…pache#8506)

### What changes were proposed in this PR?

Six operators implement `StandaloneCodeGenerator`: the three joins and
the three set operations. What they have in common is that they combine
or compare tables rather than read what is inside a row.

apache#8340 keeps the operators that work on text. Aggregate and the sort
family follow in apache#8709, and the samplers and control flow in apache#8710.

Review then found two places where the block answered a question the
engine answers differently. The hash join asked pandas for a suffix,
which appends once and then refuses the duplicate it just made, and let
an outer join's holes cost an integer column its type.

Running the engine on those cases found the platform out of step with
itself. HashJoin declared a right column's new name by checking only the
left names, while the executor also avoids the other right names. So a
right `x` beside a right `x#@1` was declared as a second `x#@1`, and one
value was lost. An unmatched right row in an outer join kept its raw
names and landed in the left column. Both now go through one renaming
rule in `JoinUtils`.

The shared table then found one more. In a right or full outer join on
keys both sides name alike, the engine writes an unmatched right row's
key into the left key column, and the export left it empty. The engine
had its own half: an unmatched right key named like a left payload
column landed in that payload. The export now fills the key, and the
engine leaves it out of the payload.

The set operations matched rows the way pandas does. The engine's
HashSet compares rows with Scala's `==`, under which NaN equals nothing,
and hashes them by each double's bits, which tell 0.0 from -0.0. The
export now selects rows by a key that follows both rules.

A probe worker that received no build rows could not name an unmatched
right row's columns, because it read the left names off the first build
row. This happens when the left input is empty or no left key hashes to
that worker. The runtime now records each input port's declared schema
on the executor before the port finishes
(`OperatorExecutor.inputSchemas`, filled in `EndChannelHandler`), and
the probe reads the left names from it. This is the Scala counterpart of
what apache#8766 does for Python operators.

### Any related issues, documentation, discussions?

Part of apache#8325, step 11a; apache#8709 and apache#8710 follow. That issue lists the
set in order.

The set operations and joins keyed on a null or a NaN need the nullable
dtypes apache#8704 reads an Arrow file into. Without it a null and a NaN share
a slot and both behave as they did before, so this PR is no worse on its
own and only complete alongside that one.

Closes apache#8505, the task this change is the whole of.

### How was this PR tested?

Each operator asserts the block it emits in its own spec. The interval
join reads its keys off the merged frame rather than writing over an
input column that shares a temporary's name.

The join cases the review named run in the verify tables of apache#8363, which
put the same input through the engine and through the script and compare
the two. What those tables cannot reach stays here as executed tests: a
null kept apart from a NaN in the set operations and the join key.
`HashJoinProbeOpExecSpec` pins the platform fixes.

Each set operation's spec runs its native executor and the export over
NaN, signed-zero, finite and null rows. `HashJoinProbeOpExecSpec` covers
an empty build side, and `EndChannelHandlerSpec` checks that the schema
is in place before the operator finishes the port.

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 5)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>