feat: add high-precision timestamp sorting support

[zanllp]

No description provided.

[ruro]

1. You might want to split the auto generated changes, translation related changes and actual changes to the main logic into separate commits for easier review.

2. You mentioned that the implemented behavior is still not quite right. I am assuming that you meant the tie breaking for when the timestamps end up matching? Or is there some other edge case?

3. created_time and date were referenced in 4 places in the backend code

   • scripts/iib/db/datamodel.py
   • scripts/iib/dir_cover_cache.py
   • scripts/iib/tool.py
   • scripts/iib/api.py
     This PR only adds mtime_ns/ctime_ns to scripts/iib/api.py. Is this intentional?

4. It looks like you added "High-precision" updated/created sorting methods in addition to old string-based date sorting methods. Are there any cases where sorting by the lower precision dates is preferable? Since you already implemented compareByHighPrecision* functions to fall back to low precision dates when high precision versions are not available, I would imagine that keeping both sorting methods is unnecessary.

[zanllp]

1️⃣ "Not quite right": Yep, even with ctime_ns, the sorting still doesn’t match Windows File Explorer’s behavior after multiple tests—it’s more about the core logic than tie-breaking.

2️⃣ Limited scope: Only modified files interface (and related parts) since that’s the main pain point in the file browser view. Other references only affect search sorting (less critical) and would require DB changes (higher risk).

3️⃣ Why new sorting mode: This change is experimental/unstable, so we’re opting for opt-in (IIB’s style) instead of forcing it on users. Old methods stay as fallbacks for edge cases (e.g., missing high-precision data). IIB's philosophy is to let users opt-in to unstable features rather than forcing them

4️⃣ Dist tip: Pro move—collapse dist in your github to skip generated files and focus on the logic!

[zanllp]

Actually, I'm starting to suspect I might even be using the stdlib methods wrong. The timestamps returned by ctime_ns are practically unique (no ties), yet they still don't match Windows' behavior. 🤔

[ruro]

Yes, nanosecond precision timestamp ties should be quite rare (although definitely possible with batch operations such as touch file1 file2, also the "actual" timestamp precision may depend on the underlying FS).

I am not sure, how Windows sorts files in the explorer. I am using Linux and AFAIK basically everything on Linux uses mtime_ns/ctime_ns when possible.