box: fix truncated files being uploaded successfully when the source ends early - #9785

Continues the "source ends early" sweep (5d05754 sia, a2baa97 pikpak, e1bf940 filelu,
7357fb8 internetarchive, 884b28c azurefiles, 18fa445 compress).

Problem

(*Object).upload — the single-shot path taken when the size is at or below
upload_cutoff (50 MiB by default) — passes the source straight to Box as the multipart
body:

opts := rest.Opts{
    Method:               "POST",
    Body:                 in,
    MultipartContentName: "contents",
    ...
}

No ContentLength is set, so the request is chunked and a source that stops short simply
produces a shorter body. Box accepts it, returns one entry, and the upload is reported as a
success with a truncated file stored.

uploadMultipart is not affected: it fills each chunk with io.ReadFull, which returns
io.ErrUnexpectedEOF when the source ends early.

Fix

Wrap the body in readers.NewCountingReader and compare the bytes actually read against the
declared size, matching the sia fix. size is already computed in Update and passed to
uploadMultipart; it is now passed to upload as well.

Verification

go build ./..., go test ./backend/box/... and golangci-lint run ./backend/box/...
(0 issues) all pass. RCLONE_CONFIG=/notfound go test ./... is unchanged from master:
cmd/gitannex and cmd/serve/s3 fail identically before and after this commit on my
machine (no git-annex or minio binary locally). No Box remote here, so the backend
integration tests have not been run against a real remote.

Possibly the same, not yet checked

While looking for this I noticed four more backends that stream the source with no
ContentLength and no byte-count check, so they may have the same problem — flagging rather
than claiming, as I have not confirmed any of them:

yandex (yandex.go:1135), gofile (gofile.go:1450), filefabric
(filefabric.go:1276), googlephotos (googlephotos.go:1198).

Happy to follow up on those if useful.