[refactor-with-go] without a definite log specification

- [x] I have searched the [issues](https://github.com/apache/dubbo-admin/issues) of this repository and believe that this is not a duplicate.
- [x] I have checked the [REAMDE](https://github.com/apache/dubbo-admin/blob/develop/README.md) of this repository and believe that this is not a duplicate.

In the refactor-with-go branch, the zap log library is configured in the pkg/logger package, but the log information is not printed correctly through zap in some existing services. It is suggested that the community can unify the log specification of dubbo-admin-go, especially the log information of Error level output in error handling.

refactor-with-go 分支中，pkg/logger 包内配置了 zap 日志库，但是已有的部分 services 内并没有通过 zap 正确打印日志信息。建议社区可以统一 dubbo-admin-go 的日志规范，尤其是错误处理中通过 Error 级别的日志打印错误 message。

## This is a proposal about log specification of dubbo-admin-go.

- Use the existing zap framework under `pkg/logger` as the only logger, don't use the logger in `dubbo.apache.org/dubbo-go/v3/common/logger`
- In service layer, every time an error is generated, its error message must be printed through log
- There is no need to print logs in handler layer, and we should return error messages directly through http responses
- The zap logging framework also should be used in unit tests
- Categorize logs, and when indexing logs, you can quickly search through specific keywords

Start by reviewing the zap configuration in pkg/logger and tracing how existing services and handlers currently emit or return errors. Then inspect the unit tests to identify logger usage and define consistent error-level messages and searchable categories. Done means the affected services use pkg/logger consistently, handlers return errors without logging, and tests use the same framework.

Written by the indexing model from the issue text.