[Bug] When calling the interface of the TRIPLE protocol, after a long time of free, it always fails for the first time

### Pre-check

- [X] I am sure that all the content I provide is in English.

### Search before asking

- [X] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar issues.

### Apache Dubbo Component

Java SDK (apache/dubbo)

### Dubbo Version

Dubbo java 3.2.5
Java 21
Spring Boot 3.2.3
Alibaba Spring Cloud 2023.0.0.0-RC1
Seata 2.0
Nacos

### Steps to reproduce this issue

我有一个triple协议的服务，提供了一个读文件的服务端流（详见最底的proto文件，read函数）。
I have a Triple protocol service, which provides a server stream for reading files (see the bottom Proto file for details, read function).

问题：
Question:
服务启动时，访问此接口是正常的（能打印“bbb”），我命名这次为 Action-A。
但是不做操作过1~2个小时候后，调此接口，就没有再执行成功了（没有打印出“bbb”），我命名这次为 Action-B。
然后紧接着再调用此接口，又正常了，我命名这次为 Action-C。
When the service starts, the access to this interface is normal (it can print "BBB"), and I named this time Action-A.
However, after 1 to 2 hours, the interface was adjusted, and it was not successfully executed (the "BBB" was not printed). I named it Action-B this time.
Then call this interface immediately, it is normal, I named this time Action-C.

----------------

```java
@DubboService(protocol = "tri", retries = 1) // Has been tried to 0 or 1
@RequiredArgsConstructor
public class ExcelFileResourceDubboGrpcImpl implements ExcelFileResourceDubboGrpc {
@Override
public void read(ReadRequest readRequest, StreamObserver responseObserver) {
System.err.println("bbb"); // Looking forward to printing "bbb", but not
}
}
```

```proto
syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.xxxxxxxxxxx.protobuf.ExcelFileResource";

package proto.ExcelFileResource;

service ExcelFileResourceDubboGrpc {
// 读取
rpc read(ReadRequest) returns (stream ReadResult) {}
}

// Ignore the definition of message
```

```yaml
dubbo:
application:
name: ${spring.application.name}
qos-enable: false
# 3.2.0+默认为严格模式
serialize-check-status: WARN
# 3.2.0+默认为true
check-serializable: false
trust-serialize-class-level: 4
registry:
address: nacos://${spring.cloud.nacos.discovery.server-addr}
parameters.namespace: ${definition.nacos-namespace.mes-dubbo-registry}
provider:
retries: 0
validation: jvalidationNew
token: true
timeout: 60000
consumer:
# 在启动时检查依赖的服务是否可用
check: false
retries: 0
validation: jvalidationNew
timeout: 60000
protocols:
dubbo:
name: dubbo
port: -1
default: true
tri:
name: tri
port: -1
default: false
```

### What you expected to happen

期初我以为是dubbo有关于“长时间空闲”的策略，但是我没找到相关信息。
At first I thought dubbo had a "long idle" policy, but I couldn't find that information.

然后我尝试增加重试次数，但意外的是，它并不像是“失败”，而是“无响应”，并没触发重试。
I then tried to increase the number of retries, but to my surprise, it didn't look like "failed", it looked like "no response" and didn't trigger a retry.

### Anything else

_No response_

### Are you willing to submit a pull request to fix on your own?

- [ ] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Start with the Java service implementation and the proto read RPC shown in the report, then reproduce Action-A, the 1–2 hour idle period, Action-B, and Action-C using the tri protocol configuration. Trace the first post-idle request and its response behavior; done means identifying why the first call gets no response and documenting or implementing a verified fix.

Written by the indexing model from the issue text.