fix(replication): quote the ETag in the single-PUT size guard message (#7075)

The guard added in #7021 fails a >5 GiB single-PutObject replication up
front instead of streaming the body to a target that must reject it. Its
message asserted a conclusion: "was not written as multipart on the
source ... re-upload it with multipart". That text is only as right as
the transport decision feeding it, and until #7047 that decision was
wrong for multipart objects carrying a full-object checksum. On 1.0.0-rc.5
a 768-part object was misrouted to the single-PUT path, and the new
default-level error line told the operator to re-upload as multipart an
object whose own ETag ended in -768.

State the evidence instead of the conclusion. The message now quotes the
ETag the decision was read from and says what was read from it (no
part-count suffix), so an operator can check the line against the
object's listing. A misroute then reads as a visible contradiction --
a suffixed ETag on a single-PUT line -- and the message says that case is
a transport-selection defect to report, not something to fix by
re-uploading. A missing or empty ETag is printed as <none> rather than
hidden.

The routing itself is already fixed by #7047; this changes only what the
guard says when it fires.

docs/operations/replication-object-size-limits.md

@@ -85,12 +85,19 @@ reached its target.
 ERROR ... event=replication_object_failed bucket=photos object=backups/vm-image.qcow2
       version_id=... arn=arn:replication::wasabi endpoint=s3.wasabisys.com
       op_type=OBJECT size=6442450944 replication_status=FAILED
-      error="object of 6442450944 bytes was not written as multipart on the source and
-             exceeds the 5368709120 byte single-PutObject limit of an S3 target;
-             re-upload it with multipart to make it replicable"
+      error="object of 6442450944 bytes exceeds the 5368709120 byte single-PutObject
+             limit of an S3 target; its ETag 767e7a8379c0f62c39e0ceeea0e13de9 has no
+             part-count suffix, so replication uses a single PutObject and does not
+             re-chunk; if the object is in fact multipart this is a transport-selection
+             defect, otherwise re-upload it as a multipart upload to make it replicable"
       Replication failed for object
 ```
 
+The line quotes the ETag the transport decision was made from. Check it against
+the object's own listing: an ETag with a `-<part count>` suffix on this line
+means the object is multipart and was misrouted, which is a RustFS defect to
+report, not a reason to re-upload.
+
 The `error` field carries the target's own error code and message where the
 target produced one, so a remote rejection is diagnosable without lowering the
 log level and reproducing. It is passed through the same redaction as the