[Bug Report] Cubelet restart/upgrade hangs while loading existing shims when a stale shim is unresponsiv

Summary

Cubelet remains an active systemd service but never binds :9998, :9999, or :9966 after restart/upgrade when an unresponsive containerd-shim-cube-rs process is left behind. Startup blocks inside LoadExistingShims -> makeConnection -> ttrpc.NewClient, and the configured io.containerd.timeout.shim.load = "5s" does not cover that connection path.

Environment

• CubeSandbox version / commit: v0.7.0 / d0081641c59822e4e5653b7462e914410b81910a
• Host OS and kernel version: Kylin Linux, 6.6.0-32.18.v2505.ky11.x86_64
• KVM info (modinfo kvm):
• Deployment mode: cluster, one control node plus one compute node
• Relevant component: Cubelet

Steps to Reproduce

1. Create a sandbox and leave it in a paused/tombstone state, or otherwise make its containerd-shim-cube-rs process unresponsive.
2. Stop Cubelet or run an upgrade:

sudo systemctl stop cube-sandbox-cubelet.service
sudo systemctl start cube-sandbox-cubelet.service