docs: clarify Helm upgrade behavior for manually edited ConfigMaps

[spencercjh]

What would you like to be added:

Please update the HAMi configuration doc to explain the risk of editing Helm-managed ConfigMaps with kubectl edit.

Current doc says users can edit the global device config with:

kubectl edit configmap hami-scheduler-device -n <namespace>

But hami-scheduler-device is also managed by the Helm chart.

Suggested doc changes:

1. Recommend Helm values / chart config as the main way to make persistent config changes.
2. Keep kubectl edit, but mark it as a temporary or troubleshooting method.
3. Add a note that changes made with kubectl edit may be overwritten by the next helm upgrade.
4. If users must edit the ConfigMap manually, suggest backing up the current config before upgrade.
5. After upgrade, users should restore only the fields they need to keep. They should not replace the whole old ConfigMap.
6. For fields that already have chart values, suggest using chart values first.

Why is this needed:

The current doc does not explain that hami-scheduler-device is managed by Helm.

If a user changes this live ConfigMap with kubectl edit, the change is not saved back to Helm values or the chart manifest. On the next helm upgrade, Helm may render the ConfigMap again and overwrite the manual change.

This can confuse users. They may think kubectl edit is a stable way to keep this config, but it is not safe across Helm upgrades.

Anything else we need to know?:

Related doc:

https://project-hami.io/docs/userguide/configure

Related sections:

• Device Configs: ConfigMap
• Node Configs: ConfigMap
• Chart Config: Parameters

[spencercjh]

If you agree with my point of view, I can submit a PR to fix it.