Fix docker cp success message to report actual content size instead of tar stream size

[4RH1T3CT0R7]

• Fix copyFromContainer() to use the file size from the container API stat response instead of the tar archive byte count
• Fix copyToContainer() to compute the actual local content size before tarring instead of reporting the tar stream size
• Add localContentSize() helper that returns the total size of regular file content at a given path (single file or recursive directory walk)

Fixes #5777

Description

docker cp currently reports the TAR archive stream size in its "Successfully copied" message. Because TAR format adds headers and 512-byte block padding, this
is always larger than the actual content. For example, copying an empty file reports "Successfully copied 1.54kB" instead of "0B", which is misleading.

For copyFromContainer: the container API already returns PathStat.Size with the exact file size, so we use that directly for regular files. For directories,
Stat.Size only gives the directory entry size (not contents), so we fall back to the tar stream size as the best available approximation.

For copyToContainer: we compute the actual content size from the local filesystem before creating the tar archive. For files this is the file size; for
directories it's the sum of all regular file sizes. If the size computation fails for any reason, we fall back to the tar stream size.

The live progress indicator is unchanged and still shows tar stream throughput, which is the correct metric during transfer.