fix(naming): do not force clusterName to DEFAULT in v3 HTTP API

[daguimu]

Problem

When calling the v3 HTTP API to list instances without specifying a clusterName, the API returns NOT_FOUND for services that use non-default cluster names (e.g., cluster-hba). The same query via gRPC correctly returns all instances.

Root Cause

InstanceListForm.fillDefaultValue() forces an empty clusterName to "DEFAULT". Then CatalogServiceV2Impl.listInstances() does an exact match — if the service has no cluster named "DEFAULT", it throws NacosException.NOT_FOUND.

The gRPC path (ServiceQueryRequestHandler) treats empty cluster as an empty string, which flows into ServiceUtil.doSelectInstances() where an empty cluster produces an empty clusterSets, causing checkCluster() to return true for all instances.

Fix

• InstanceListForm.fillDefaultValue(): Use StringUtils.EMPTY instead of UtilsAndCommons.DEFAULT_CLUSTER_NAME when clusterName is blank, so the v3 HTTP path passes an empty string just like gRPC does.
• CatalogServiceV2Impl.listInstances(): Skip the cluster-existence check when clusterName is blank, letting ServiceUtil.selectInstances() handle the empty-cluster case correctly (return all instances).

Tests Added

Change Point	Test
InstanceListForm: blank clusterName → empty string	InstanceListFormTest.testFillDefaultValueWhenClusterNameIsBlank()
InstanceListForm: provided clusterName preserved	InstanceListFormTest.testFillDefaultValueWhenClusterNameIsProvided()
InstanceListForm: default namespace/group	InstanceListFormTest.testFillDefaultValueForNamespaceAndGroup()
InstanceListForm: missing serviceName throws	InstanceListFormTest.testValidateThrowsExceptionWhenServiceNameIsBlank()
CatalogServiceV2Impl: blank cluster returns all instances	CatalogServiceV2ImplTest.testListInstancesWithBlankClusterNameReturnsAll()
CatalogServiceV2Impl: null cluster returns all instances	CatalogServiceV2ImplTest.testListInstancesWithNullClusterNameReturnsAll()

Impact

Only affects the v3 HTTP instance-list endpoint when clusterName is omitted. No change to gRPC behavior or any other API.

Fixes #14650

[github-actions]

Thanks for your this PR. 🙏
Please check again for your PR changes whether contains any usage/api/configuration change such as Add new API , Add new configuration, Change default value of configuration.
If so, please add or update documents(markdown type) in docs/next/ for repository nacos-group/nacos-group.github.io

---

感谢您提交的PR。 🙏
请再次查看您的PR内容，确认是否包含任何使用方式/API/配置参数的变更，如：新增API、新增配置参数、修改默认配置等操作。
如果是，请确保在提交之前，在仓库nacos-group/nacos-group.github.io中的docs/next/目录下添加或更新文档（markdown格式）。

[KomachiSion]

Duplicate with #14674

If this PR no response and no match the merged status, This PR will be merged.

[KomachiSion]

@daguimu ci not pass, please fix.

[daguimu]

@KomachiSion I've rebased onto the latest develop branch. The previous CI failure was caused by a flaky test (ConfigFuzzyWatchGroupKeyHolderTest) that has since been fixed on develop. Could you please approve the CI run? Thanks!