DefaultTransactionManager ignore server error(ResultCode=Failed) and return GlobalStatus

- [ ] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate.

### Ⅰ. Issue Description
我在编写mock-server测试case的时候发现，目前DefaultTransactionManager会忽略除begin以外的所有异常，然后正常的返回一个status。按我理解这里的情况是分两种的：
第一种：TC正常接收到2阶段请求且落库了，然后在后续过程中遇到问题，此时TC可能不希望用户做任何处理，只要等待TC重试调度即可。
另一种情况：TC接收请求后遇到了意外的异常，甚至没有持久化成功但可以返回rpc请求，客户端应该是需要有所感知的，所以我认为TM至少需要打印错误日志。
也有可能是还有其他处理逻辑我没看到，不过按照预期这种情况mock是需要能感知的。如果有相关处理逻辑建议还是要移动回DefaultTransactionManager

While writing test cases for a mock-server, I discovered that the current DefaultTransactionManager ignores all exceptions except 'begin', and then returns a status normally. In my understanding, there are two scenarios here:

1. The TC normally receives a 2-phase request and logs it, but encounters issues in subsequent processes. In this scenario, the TC might not wish for the user to take any action, simply waiting for the TC to retry scheduling may suffice.
2. In another scenario, the TC encounters an unexpected exception after receiving a request. In this case, the client should be made aware of the issue, so I believe the TM should at least log an error.

There might be other processing logic that I haven't noticed. However, as per expectation, such scenarios should be detectable in a mock. If there are relevant processing mechanisms, it's advisable to move them back to the DefaultTransactionManager.

### Ⅱ. Describe what happened


### Ⅲ. Describe what you expected to happen

### Ⅳ. How to reproduce it (as minimally and precisely as possible)

1. xxx
2. xxx
3. xxx

Minimal yet complete reproducer code (or URL to code):

### Ⅴ. Anything else we need to know?

### Ⅵ. Environment:

- JDK version(e.g. `java -version`):
- Seata client/server version:
- Database version:
- OS(e.g. `uname -a`):
- Others:

Start at DefaultTransactionManager and trace how exceptions other than begin are handled when a mock server returns ResultCode=Failed. Review or add mock-server test cases covering persisted two-phase requests versus unexpected failures; done should make the intended logging and client-visible status behavior explicit and verified.

Written by the indexing model from the issue text.