Requiring <chrono> is a normative change, not editorial. It's not necessary (implementations would be required to ensure the necessary types are available, but that doesn't mean the whole of <chrono> has to be).

Would the rest of the proposed change qualify as editorial if I remove the inclusion of <chrono>?

I'm not sure if the rest is editorial even. Removing redundant wording that applies to an unspecified type that is no longer used is editorial, but I wonder if the wording about reflecting the OS-dependent resolution and range of file time values should be present on file_clock instead. If we remove that wording then nothing would be left to suggest that file_clock should be able to represent file timestamps.

In [time.syn], there's a

template<class Duration>
using file_time = time_point<file_clock, Duration>;

which looks pretty close to file_time_type defined in [fs.filesystem.syn].
I also notice that the suggested change leaves the resolution/range wording in, applying to file_time_type, not to file_clock. Which probably is appropriate, since we then take the clock's duration type.
In short, the suggestion change of removing discussion of trivial-clock seems correct and editorial to me.

It would be good to add "that is capable of representing and measuring file time values." to the definition of file_clock in [time.clock.file.overview] p1, though. @zygoloid, is that still editorial?

We could suggest that change to [time.clock.file.overview] as part of the resolution of LWG issue 3145, which is currently under discussion on the reflector.

The old type was required to be "capable of representing and measuring file time values". The new type "should [have sufficient] resolution and range [to] reflect the operating system dependent resolution and range of file time values", which seems like a strictly weaker requirement -- and appears to be an intentional weakening.

(I would note that there are some Linux file systems that represent 128-bit file times, and we probably want to permit a 64-bit file time implementation regardless, so the existing "should" wording may well be the right thing. But whether it's right or not is up to LWG.)

That is to say: I'm merging this to remove the remaining vestige of a deleted type; retaining the "capable of representing and measuring file time values" and applying it to the new type would in my view not be editorial.