[Compatibility BUG] Modification time changes when a file is mv'ed across file systems.

If a file is mv'ed across file-systems then the modification time ends up set to the time of the move.

It should retain the original value.

Note that this may be related to https://github.com/uutils/coreutils/issues/9635.

This was noted in Kubuntu 25.10.

Here is a test script to show the problem.
-***-
#!/bin/sh

touch -t 202604011000 test-file1
touch -t 202604011000 test-file2
echo "Starting state of files"
ls -l test-file?
echo

echo "mv to same file-system"
mv test-file1 test-mv1
gnumv test-file2 test-mv2
ls -l test-mv?
echo

echo "mv to another file-system"
mv test-mv1 /var/tmp/test-mv1
gnumv test-mv2 /var/tmp/test-mv2
cd /var/tmp/
ls -l test-mv?
-***-

The result (for me - on Kubuntu 25.10) is:

Starting state of files
-rw-r--r-- 1 myid000 mygrp 0 Apr 1 10:00 test-file1
-rw-r--r-- 1 myid000 mygrp 0 Apr 1 10:00 test-file2

mv to same file-system
-rw-r--r-- 1 myid000 mygrp 0 Apr 1 10:00 test-mv1
-rw-r--r-- 1 myid000 mygrp 0 Apr 1 10:00 test-mv2

mv to another file-system
-rw-r--r-- 1 myid000 mygrp 0 Apr 10 01:27 test-mv1
-rw-r--r-- 1 myid000 mygrp 0 Apr 1 10:00 test-mv2

The modification time of test-mv1 has been changed by the rust core-utils mv command.

NOTE: that is ALSO changes the last-accessed time - that must also retain the original setting!

Start by reproducing the cross-filesystem case with the shell script in the issue, comparing Rust mv with gnumv and checking both modification and last-access times. Trace the mv command's cross-filesystem path and determine how metadata is copied; done means both timestamps retain their original values after the move.