fix(rclone): guard nil Item in GetFilesSize to avoid panic

[lovehunter9]

Summary

Guard against resp.Item == nil in the file branch of
(*rclone).GetFilesSize, so a missing remote no longer crashes
the request handler.

Background

When precheck runs against a cloud source whose path lacks a
trailing slash, FileParam.IsFile() reports isFile=true and
GetFilesSize takes the Stat(..., FilesOnly: true) branch.
If the underlying remote actually resolves to a directory (or
does not exist at all), rclone's operations/stat endpoint
responds with:

{ "item": null }

The previous code dereferenced resp.Item.Size unconditionally
and panicked with runtime error: invalid memory address or nil pointer dereference. Hertz's recovery middleware kept the
process alive but the response was already partially written, so
the client saw an HTTP 200 with a corrupted body — symptom on
the wire was a body of just 1 instead of a normal JSON envelope.

Fix

Treat resp == nil || resp.Item == nil as "file not found" and
return a descriptive error. precheck.checkCloud already wraps
any GetFilesSize error into the standard Source path to copy does not exist or is not accessible. 500 response, so this
aligns the cloud failure surface with the existing sync-source
behaviour.

The same nil-guard pattern is already used in
pkg/drivers/clouds/service.go (the file-stat path), so this is
consistent with prior art in the codebase.

Test plan

• Cloud paste (S3 / Tencent COS / Drive) with source missing
  the trailing slash on a path that resolves to a directory
  → expect HTTP 500 + "Source path to copy does not exist or
  is not accessible.", no panic in server logs.
• Cloud paste with a valid file source (with or without
  trailing slash) still succeeds end-to-end.
• Cloud paste with a valid directory source (trailing
  slash present) still succeeds end-to-end.

Made with Cursor