fix: repair CTCC Cloud LVDN deployment

[ickeep]

Summary

• fix the CTCC Cloud LVDN provider type mismatch (ctcccloud-ldvn vs. ctcccloud-lvdn)
• route LVDN domain APIs through the documented cdnapi-global.ctapi.ctyun.cn endpoint
• use the documented paths and HTTP methods for domain list, detail, and update requests
• accept the current top-level code response format and normalize domain-list results for existing callers
• correct the misleading cdn.QueryDomainList log label

Root cause

The UI persists ctcccloud-lvdn, but the backend registry used the misspelled ctcccloud-ldvn, so deployment failed before constructing the provider.

After fixing the registry key, the domain APIs still used the legacy ctlvdn-global endpoint and an outdated /v1/domain/query-domain-list route/response shape. The current CTCC Cloud API documents these requests under cdnapi-global.ctapi.ctyun.cn.

Validation

• go test ./internal/domain ./internal/certmgmt/deployers ./pkg/sdk3rd/ctyun/lvdn
• git diff --check
• built a patched v0.4.28 linux/amd64 image and deployed it to an existing Certimate instance
• ran a real LVDN workflow using certificate-SAN matching; certificate reuse, domain discovery, and certificate updates for three matched domains completed successfully

Fixes #1395

[fudiwei]

从修改结果上看，老的 endpoint 和 client 已经没有用了吧？为啥不直接替换掉呢？