[Studio][Bug] Blanking a NameServer registry entry description, k8s namespace or k8s id has no effect

## 1. Symptom

Blanking the K8s namespace, K8s ID or description of a NameServer registry entry has no effect. In the Studio cluster page's registry edit dialog, clearing one of those fields and saving reports success and reloads the list, and the previous value is back in the row.

## 2. Root cause

`server/src/main/java/org/apache/rocketmq/studio/cluster/nameserver/NameserverRegistryService.java:79-85`

```java
entity.setName(name);
entity.setNamesrvAddr(NamesrvAddrParser.normalize(command.getNamesrvAddr()));
entity.setK8sNamespace(command.getK8sNamespace());
entity.setK8sId(command.getK8sId());
entity.setDescription(command.getDescription());
...
int updated = nameserverMapper.updateById(entity);
```

The update request replaces every editable field of the entry - `UpdateNameserverRegistryDTO.name` and `.namesrvAddr` are `@NotBlank` (`UpdateNameserverRegistryDTO.java:35-41`), and the three optional columns are copied unconditionally - so the service's contract is "the stored entry matches the request".

Two things then line up to lose the clear:

1. The edit dialog submits a blanked optional field as an *absent* one: `web/src/pages/cluster/index.tsx:255-257` builds the payload with `k8sNamespace: values.k8sNamespace || undefined`, `k8sId: values.k8sId || undefined` and `description: values.description || undefined`, so `command.getDescription()` etc. are `null` after a field is cleared.
2. MyBatis-Plus `updateById` omits null entity fields (`FieldStrategy.NOT_NULL`; there is no `update-strategy` override in `application.yml`), so those three columns are dropped from the SET clause and keep their previous values.

Clearing is therefore unreachable through the API: `null` means "leave the column alone" (accidentally), and there is no separate clear flag, unlike `clearApiKey` in general settings. The same mechanism was already documented and fixed for the ACL user/rule columns in #3342.

## 3. Impact

- The registry entry's annotations are write-once: an operator can add or change a K8s namespace / K8s ID / description but cannot remove it, which is exactly what is needed when an entry is re-pointed at a non-K8s deployment or a stale `k8sId` has to be dropped.
- The API response and the reloaded list disagree with the write: the save reports success, `update` re-reads the row and returns the retained value, and the dialog then shows the old text again with no error.
- `k8s_id` links a registry entry to its K8s certificate view, so a stale one cannot be cleaned up from the UI.

## 4. Reproduction

1. Create a registry entry with `k8sNamespace = "rocketmq1"`, `k8sId = "k8s-1"`, `description = "community chart cluster"`.
2. Edit it and clear the description (leave name and namesrvAddr untouched), save.
3. Effect: HTTP 200, list reloads, the description is still `community chart cluster`.
4. `SELECT k8s_namespace, k8s_id, description FROM rmq_nameserver WHERE id = ` confirms the columns were not updated.

## 5. Expected behaviour

- The stored entry matches the submitted request: an optional field the request does not carry is persisted as NULL for that entry, and a field the request does carry is written as submitted.
- No signature or DTO change is required; `updateById` stays for the non-null columns, the cleared ones are assigned explicitly.

Start with NameserverRegistryService.java:79-85, UpdateNameserverRegistryDTO.java:35-41, and web/src/pages/cluster/index.tsx:255-257 to trace how cleared optional fields reach updateById. Check application.yml for update-strategy behavior and compare the ACL clearing work in #3342. Done means clearing namespace, K8s ID, or description persists NULL while non-cleared values still update.

Written by the indexing model from the issue text.