Port assignments persist after `solo one-shot single destroy`, causing non-default ports on redeploy

[Reccetech]

Environment

• OS: Windows 11 Pro (WSL2)
• Solo: 0.68.0
• Cluster: Kind (kind-solo-cluster)

Steps to Reproduce

1. Run solo one-shot single deploy
2. Run solo one-shot single destroy
3. Run solo one-shot single deploy again

Expected Behavior

Fresh deploy uses default ports:

• Explorer: 8080
• Mirror Node: 8081
• JSON RPC Relay: 7546
• Consensus gRPC: 50211

Actual Behavior

Solo reuses the non-default ports from the previous deployment:

• Explorer: 38080
• Mirror Node: 38081
• JSON RPC Relay: 37546
• Consensus gRPC: 35211

Root Cause

solo one-shot single destroy does not delete the Kind cluster or its namespace. The solo-remote-config ConfigMap in the one-shot namespace survives destroy with stale port assignments intact. On redeploy, Solo reads these saved port values and requests them again instead of resetting to defaults.

Confirmed via:

kubectl get configmap solo-remote-config -n one-shot -o json
# portForwardConfigs still shows localPort: 38080, 38081, 37546, 35211

Mac Behavior

The bug exists on Mac but is less visible. On Mac, the default ports (8080, 8081, 7546, 50211) are typically free on a clean machine, so the first deploy uses defaults. After destroy + redeploy, the same default port values are reused — the bug is present but unnoticeable because the persisted values match the defaults. On Windows, port conflicts are more common (e.g. port 7546 may be in use), making non-default ports more likely to be saved and then incorrectly reused.

Fix

The destroy sequence should clear portForwardConfigs from the remote config before removing components, so that a subsequent deploy always starts port assignment from the configured defaults.