fix(dbprovider): repair PolarDB-X resource operations

[wallyxjh]

What this PR fixes

• use dn-0 as the PolarDB-X scaling component so replica shrink requests take effect
• keep API and edit-form CPU/memory units consistent and stop multiplying already-normalized mCPU/Mi values
• submit vertical and horizontal scaling only for components whose desired values actually changed
• generate a valid restart request with the PolarDB-X component list
• calculate volume expansion from the actual data volume templates; an existing 3Gi cluster now expands to 4Gi through gms/data instead of requesting a nonexistent dn-0/data template
• keep displayed PolarDB-X storage aligned with the edit form's logical storage value
• record PolarDB-X CPU/memory history in total form units and normalize equivalent Kubernetes quantities such as 1Gi and 1024Mi
• return resource values read back from the Cluster instead of overlaying the requested values

This includes and extends the component-selection direction from #7327 and follows the GMS/DN volume-template boundary documented in labring/kubeblocks#63.

Verification

• tsx --test for the PolarDB-X and related utility tests: 16 passed
• DBProvider production next build: passed
• Prettier check: passed
• git diff --check: passed

Read-only validation on root@192.168.128.241 confirmed Kubernetes access and the KubeBlocks deployment is 1/1 Ready. The cluster currently has two MongoDB clusters, no PolarDB-X Cluster, and no OpsRequest, so destructive/runtime PolarDB-X scaling and restart operations were not run there. The generated OpsRequest shapes and compatibility cases are covered by the added tests.