Don't print a stray blank line when try with catch or finally collects an external

[hexbinoct]

Description

Fixes #18765. Byte for byte, before:

> nu -c "try { ^nu -c 'print hi' } catch {}" | od -c
0000000   h   i  \n  \n

and after:

0000000   h   i  \n

Since 7f69d75, a try block followed by catch or finally collects the block's output first, so it can tell whether the block failed before anything starts streaming. If the tried command is an external whose stdout was not captured (it is inherited at the statement level, or redirected to a file inside the block), the output has already left the process by the time the collect runs. The collect then converted that data-less child stream into an empty string value, and printing the collected result rendered the empty string as an extra blank line.

The fix is in the shared collect helper in eval_ir.rs: when the collected data is a byte stream whose child has no captured stdout, wait for the child and produce Empty, which is exactly what the plain try { } path produces when it drains the same stream. Waiting keeps the failure semantics: a non-zero exit still becomes an error, so catch still runs (covered by a test).

Behavior that did not change, verified against an unpatched build:

• Value context still collects and trims the captured output: let x = (try { ^cmd } catch {}) still gives the trimmed string.
• $env.LAST_EXIT_CODE was not set by the collect path before and still is not.

Credit where due: neurolag bisected the inconsistency to 7f69d75, and weirdan showed it is the collection step that differs.

User-Facing Changes

try { ^external } catch { } and try { ^external } finally { } no longer print a stray blank line after the external's output. Collecting an uncaptured external (for example try { ^cmd o> file } catch {} as the value of an assignment) now produces nothing instead of an empty string.

Tests + Formatting

Added try_catch_inherited_external_output_has_no_extra_blank_line in tests/shell/mod.rs. It spawns the real nu binary and compares raw stdout bytes for the catch, finally, and catch plus finally cases, plus a failing external to prove catch still runs. The try sits in final statement position on purpose: only the final statement's value is printed, so that is the position where the fabricated empty string became visible. The test fails on current main with exactly the extra \n and passes with this change.

• cargo fmt --all -- --check clean
• cargo clippy --workspace --all-targets -- -D warnings clean
• shell:: suite 255 passed, commands::try_:: suite 41 passed (includes the pipefail experimental tests)
• cargo check -p nu-engine --target wasm32-unknown-unknown --no-default-features compiles (the new block is gated on the os feature)

After Submitting

Release notes summary - What our users need to know

try with a catch or finally block no longer prints a stray blank line after an external command's output.

[fdncred]

Thanks