fix(payload): never rename() across devices — fixes USB→internal move kernel panic

[phantomptr]

Critical bug — console kernel panic

Moving (cut & paste) a file from a USB drive to the internal SSD reliably kernel-panicked the PS5 (hard crash + reboot), reproduced every time. Copy worked fine — that difference was the smoking gun.

Root cause

The payload's handle_fs_move (and the shell mv builtin) called rename(from, to) directly with no cross-filesystem check. On this kernel a cross-device rename (USB exFAT → internal nullfs/UFS) does not return EXDEV — it panics. The client already falls back to copy-then-delete on fs_move_cross_mount, but the payload panicked before it could ever return that error.

Fix

Before rename(), stat() the source and the destination's parent dir and compare st_dev; if they differ, refuse the rename and return fs_move_cross_mount. The client then completes the move as copy+delete (byte read/write — cross-volume safe). Applied to both the FS_MOVE handler and the shell mv command. stat() on USB is safe (FS_COPY already stats the same paths).

Hardware verification (real PS5 Phat, FW 5.10, USB drive attached)

• ✅ USB→/data move (the panic scenario): now returns fs_move_cross_mount, console stays alive — no panic
• ✅ Intra-volume move (USB→USB): still rename()s successfully, no regression
• ✅ Readiness probe (3.3.20): {ready:true} on the idle console
• Throwaway test files only (a copy of an 11-byte file); all cleaned up, user data untouched

Payload compiles -Werror clean. Client typecheck/lint green.

Release 3.3.21.