fix(cli): return error instead of panicking on invalid move-node/join-window direction

[YuriNachos]

Problem

A typo in the direction argument of rift-cli execute layout move-node|join-window|consume-or-expel-window (e.g. move-node rignt)
panicked with exit code 101 instead of returning a clean error:

$ rift-cli execute layout move-node rignt
thread 'main' panicked at crates/rift-protocol/src/layout.rs:58:18:
Invalid direction string: rignt

The three commands fed the raw clap direction: String straight into
From<String> for Direction, which panic!s on any token outside
left/right/up/down. The sibling focus commands already validate
this input through parse_focus_direction and print
Error: Invalid focus direction '…' with exit 1.

Changes

• Route MoveNode, JoinWindow, and ConsumeOrExpelWindow through
  parse_focus_direction(&direction)? in map_layout_command
  (src/bin/rift-cli.rs), matching the existing focus/switch path and
  the neighbouring SetLayout arm. Invalid directions now yield
  Error: Invalid focus direction 'foo'; must be left, right, up, or down
  with exit 1; valid directions are unchanged.
• Add regression test invalid_move_node_direction_returns_error_not_panic
  asserting the invalid path is an Err containing "Invalid focus direction" (pre-fix this panicked).

The From<String> for Direction impl in crates/rift-protocol/src/layout.rs
is intentionally left untouched; it is simply no longer reached from CLI
input.

How I tested this

• cargo nextest run -E 'test(invalid_move_node_direction_returns_error_not_panic)'
  → PASS (was a panic before the fix).
• Manual: rift-cli execute layout move-node|join-window|consume-or-expel-window <bad>
  → exit 1 with the one-line Invalid focus direction error (previously
  exit 101 panic).
• Parity: rift-cli execute layout move-node left still parses correctly and
  reaches the IPC layer (no false rejection of valid directions).
• Gate: cargo +nightly fmt --all --check --verbose ✅,
  cargo check --locked ✅,
  cargo nextest run -E 'not test(/actor::reactor::tests/)' → 384 passed.
  Full cargo nextest run --no-fail-fast: the only failures are the 12
  pre-existing actor::reactor::tests host-env baseline (multi-display
  topology), unrelated to this change.

Scope: CLI-input validation only — no changes to the layout engine, IPC,
config, or Direction semantics for valid values.

[YuriNachos]

Force-pushed to add regression coverage: the first push only tested move-node. This update adds identical non-panic assertions for join-window and consume-or-expel-window, plus a valid_layout_direction_is_accepted_and_normalized parity test (mixed-case / surrounding-whitespace input like " Left " is accepted and normalized, matching the sibling focus/switch path). cargo nextest run direction → 9/9 pass. No production-code change vs the first push — only additional tests.

[YuriNachos]

The red test check is a pre-existing failure on main, not something this branch introduces.

This PR touches exactly one file, src/bin/rift-cli.rs. The failing test is in the reactor:

thread 'actor::reactor::tests::ax_invalidation_after_quarantine_release_preserves_live_layout_state'
panicked at src/actor/reactor/tests.rs:4191:5
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 508 filtered out

Nothing in the CLI binary is reachable from that test. And the same rust workflow is red on main itself, on the two most recent runs:

2026-08-08 14:18  failure  rust
2026-08-08 02:03  failure  rust
2026-08-05 02:09  success  rust

So the breakage landed on main between 2026-08-05 and 2026-08-08. Happy to look at the reactor test in a separate PR if it would help — just say the word. This one is ready for review as it stands.

[YuriNachos]

The failing test ax_invalidation_after_quarantine_release_preserves_live_layout_state (src/actor/reactor/tests.rs:4191) is pre-existing on main — it fails identically in recent main runs (31261640405 "feat: unstripped release profile"; 31234104784 #440 "make ax destroy not be authoritative"), same panic location. It exercises accessibility/reactor layout invalidation after quarantine release, unrelated to the CLI direction parsing this PR changes. No fix needed here.

[YuriNachos]

Leaving a quiet note here since this PR hasn't had any eyes yet: it turns the CLI panic on an invalid direction argument into a proper error, with non-panic regression tests for move-node, join-window and consume-or-expel-window. The red test check is the same reactor failure that's currently failing on main itself — evidence and run links are upthread — and format passes. I also have #444 and #445 open in a similar state, so if one of the three is more valuable to you than the others, point me at it and I'll prioritize that one.