bisync: fix listings ignoring a modtime less than 1s older - #10012

What does this change do?

Before this change, ls.put kept a listing entry's old modtime whenever the new one was less than a second earlier. That rule was a companion to ConvertPrecision, which truncated modtimes before they were recorded, so a truncated time wouldn't overwrite the precise original. 956c296 removed ConvertPrecision (#8025) but left the rule behind, so now it only fires when a file really does have an earlier modtime -- and records a time the file doesn't have.

That shows up two ways:

• --resync aborts with "path1 and path2 are out of sync" when Path1's version is slightly older than Path2's (default --resync-mode path1), and running --resync again fails the same way.
• A phantom change on the next run, e.g. when a file changes on a lower-precision remote within the same second as the old version and gets copied down to local. The local file takes the coarse time, but the listing keeps the old precise one, and since same-side comparisons use that side's own modify window (1ns for local), bisync sees a change that didn't happen.

After this change, bisync records the modtime it's given. Comparisons already account for differences in precision through the modify window. It's just a 6-line deletion + unit tests.

I also tried the opposite approach -- keeping the more precise of two times within the modify window -- but testing showed that's exactly what causes the phantom change on the higher-precision side. The listing there needs to match what the file actually has.

This also pairs with #10001: the identical files that #10001 records go through ls.put too, so without this fix a file with a slightly older modtime can keep coming back as "changed on both paths" on every run.

Linked issue

No issue -- I found this while adding test coverage for bisync. Related: #8025, #10001

Checklist

• This change is trivial OR it has been discussed and agreed in the linked issue.
• I have read the contribution guidelines.
• (If I used AI tools to help write this code) I have read and understood the AI-assisted contributions guidance, and I have tested and take ownership of this change myself.
• I have added tests for all changes in this PR if appropriate.
• I have added documentation for the changes if appropriate.
• All commit messages are in house style.
• (Backend changes only) test_all passes for this backend and if submitting a new backend can provide a test account for the integration tester - see CONTRIBUTING.md.
• This Pull Request is ready for review.