executor: a per-element operator joins on IFS[0], not a space (#752)

[berrym]

Closes #752.

The defect

"${arr[*]}" joins on the first character of IFS. With a per-element operator applied it joined on a hardcoded space, so the two forms disagreed side by side:

$ lush -c 'IFS=,; arr=(ab xy); printf "<%s>" "${arr[*]}"'
<ab,xy>
$ lush -c 'IFS=,; arr=(ab xy); printf "<%s>" "${arr[*]#a}"'
<b xy>                          # bash: <b,xy>

An empty IFS was wrong in the other direction — it must concatenate with no separator, and produced spaces.

The primitive already existed

ifs_join_separator and join_strings_with_sep are used at five other join sites, introduced by #518 to retire exactly these hardcoded-space joins. This site was missed because it lives in the operator dispatch rather than in the plain vector path.

ifs_join_separator carries the load-bearing unset-vs-empty distinction (unset → space, empty → no separator), which is why the append is guarded on the separator's length rather than assuming one byte.

Field count deliberately untouched

"${arr[@]}" with an operator should contribute N fields rather than being joined at all — that is #749, and it is a different question in a different place. This join is what a [*] form legitimately wants; the code comment says so explicitly, so a later reader does not mistake it for a decision about [@].

Verification

• 9 new checks: a custom IFS across the operator families (#, ^^, //), positionals, the empty-IFS concatenation and the unset-IFS space, the operator-free form that must not change, a single element needing no separator, and an empty array.
• 5 of the file's 26 checks fail against the parent build, with a control proving the binaries differ.
• Full suite 197/197. ASan 65/65; the test 1/1 under ASan.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!