fix: SFTP sync failures from restricted-shell md5sum and checksum fallback

[7MS8]

Split out of #406 per reviewer request (separate unrelated fixes into their own PRs).

Bug

On SFTP remotes with restricted shells (e.g. Synology NAS), when the task has "use MD5 checksum" enabled, rclone's --checksum option makes it call md5sum/sha1sum over SSH to verify transfers. A restricted shell often can't see paths that are only exposed via SFTP (not a general SSH login), so every transfer fails with:

failed to run "md5sum /path/to/file": No such file or directory
corrupted on transfer: md5 hashes differ

Fix (two parts, kept together because the first alone regresses)

1. Disable the remote hash commands for SFTP remotes (--sftp-md5sum-command none, --sftp-sha1sum-command none) so rclone doesn't attempt them over SSH at all.
2. Disabling both, on its own, leaves rclone with no common hash type to compare when --checksum is still requested — it silently falls back to a size-only comparison and ignores modification time entirely, so a changed file that happens to keep the same byte size is never re-synced (--checksum is in use but the source and destination have no hashes in common; falling back to --size-only in sync.log). Skip --checksum entirely for SFTP remotes so rclone uses its default size+modtime comparison instead.

Why this doesn't touch every SFTP remote's ability to verify by hash (open question raised in review)

This trades hash-based transfer verification for size+modtime comparison, for every SFTP remote, not just restricted-shell ones — this was raised as a concern in review of the original bundled PR (#406). A per-remote opt-out toggle (only disable remote hash commands for remotes that actually need it) would be a better long-term fix; that's intentionally left out of this PR to keep it minimal and is a candidate for a focused follow-up if wanted.

Reproduction

• Remote: SFTP, restricted-shell server (reproduced against a Synology NAS). Task: "use MD5 checksum" enabled.
• Sync any file: before this fix, transfer fails with the md5sum ... No such file or directory / corrupted on transfer errors above.
• After part 1 alone (not in this PR, described for context): transfer succeeds, but edit a synced file so its byte size stays exactly the same while content and mtime change (e.g. flip one character) and sync again — the file is silently skipped (sync.log shows the falling back to --size-only message), the change is never picked up.
• After this PR (both parts): transfer succeeds, and the same-size/changed-content file is correctly detected via modtime and re-transferred (sync.log: Copied (replaced existing)).

Test plan

• Verified end-to-end against a live Synology SFTP remote and on a physical Pixel 7a (GrapheneOS): restricted-shell transfers succeed, same-size/changed-content files are correctly detected and re-transferred, unrelated files correctly no-op on a second sync.
• Local build compiles (./gradlew :app:compileOssDebugSources).

[scr4bble]

Following up on my concern in #406: I don’t think this should be merged as-is. It silently ignores a user-visible setting and disables checksums for all SFTP remotes, including those where they work correctly.

Given that the project is currently in some kind of a maintenance mode, my suggestion would be to keep the fix as small and narrowly scoped as possible: preserve the existing checksum behavior, clearly expose the actual rclone error, and optionally add a short hint suggesting path_override or disabling Use MD5 checksum for the affected task.

More advanced solutions, such as better capability detection or UI changes, could be added to the wishlist for the planned rewrite. That would minimize the risk of regressions in the current codebase. The final approach is, of course, up to the maintainer.