ltfs_ordered_copy QoL features (type annotations, etc.)

Nobody has claimed this yet.

**Is your feature request related to a problem? Please describe.**
Not a ***problem*** per se, rather a minor inconvenience (and offer for contribution): the `ltfs_ordered_copy` script lacks several "creature comforts"/conveniences found in modern python modules (e.g.: type annotations) - I assume this is with a view to maximising compatibility.

**Describe the solution you'd like**
Without knowing the appetite of the maintainers for breaking compatibility with older python versions (and/or introducing an entirely new script with greater minimum python version requirements - messy IMHO), the following solutions could be considered:
- ***(non-breaking)*** a low-friction solution for type annotations specifically would be a [stub file](https://peps.python.org/pep-0484/#stub-files).
- ***(non-breaking)*** adding docstrings (optionally with an established style, e.g.: [numpy](https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard)) aids readability.
- ***(breaking)*** if a (new) minimum version can be established, various other readability improvements enabled by in-language features (e.g.: f-strings, more concise/readable variants of standard library functions (such as those in `pathlib`)) could be implemented.

**Describe alternatives you've considered**
The above are three "alternatives" (non-mutually-exclusive) I've considered; a fourth would be "do nothing". I personally plan to utilise some of the classes within my own work, so will likely invest effort "modernising" regardless - while I could hypothetically maintain a fork of this entire repository for the sake of one script, this overhead is a disincentive, and realistically other users are unlikely to stumble across such a fork; including modernising updates in the upstream makes this work available to a broader user base.

Start by locating the ltfs_ordered_copy script and checking the repository's supported Python versions. Review the proposed alternatives—stub files, docstrings, or newer language features—and confirm the maintainers' compatibility preference before defining the work. Done should mean an agreed, bounded modernization scope is implemented without unspecified compatibility changes.

Written by the indexing model from the issue text.