附件大小限制问题，当大小大于uint32, 会有问题

**Describe the bug (描述bug)**
message RpcMeta {
optional RpcRequestMeta request = 1;
optional RpcResponseMeta response = 2;
optional int32 compress_type = 3;
optional int64 correlation_id = 4;
optional int32 attachment_size = 5;
optional ChunkInfo chunk_info = 6;
optional bytes authentication_data = 7;
optional StreamSettings stream_settings = 8;
}
attachment_size 是int32 ，但附件没有限制大小
ProcessRpcResponse

// Parse response message iff error code from meta is 0
butil::IOBuf res_buf;
**const int res_size** = msg->payload.length();
butil::IOBuf* res_buf_ptr = &msg->payload;
if (meta.has_attachment_size()) {
if (meta.attachment_size() > res_size) {
cntl->SetFailed(
ERESPONSE,
"attachment_size=%d is larger than response_size=%d",
meta.attachment_size(), res_size);
break;
}
**int att_size** = res_size - meta.attachment_size();
msg->payload.cutn(&res_buf, att_size);
res_buf_ptr = &res_buf;
cntl->response_attachment().swap(msg->payload);
}

在获取的时候都使用了int，当附件大小大于4G时会有问题。
**To Reproduce (复现方法)**

**Expected behavior (期望行为)**

**Versions (各种版本)**
OS:
Compiler:
brpc:
protobuf:

**Additional context/screenshots (更多上下文/截图)**

Start with the RpcMeta definition and the ProcessRpcResponse path shown in the report, focusing on attachment_size and the int variables used to derive response and attachment lengths. Trace related size handling in the surrounding RPC response code. Done means attachment sizes beyond 4 GiB are handled without truncation or incorrect validation.

Written by the indexing model from the issue text.