fix(deploy): raise rollout timeout for StatefulSet's sequential update

StatefulSet's RollingUpdate replaces Pods one at a time in strict
sequence (unlike a Deployment, and unaffected by podManagementPolicy:
Parallel, which only governs initial scale-up/down) -- confirmed live:
run #152 restarted correctly (2/3 pods updated, then the 3rd) but hit
the old 120s ceiling before the last pod turned Ready, so CI reported
"failure" for a rollout that actually completed successfully seconds
later. 300s gives enough headroom for three sequential pod cycles
(image pull + start + native-Cluster rejoin) instead of tuning it to
the exact observed timing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.gitea/workflows/deploy.yml

@@ -35,4 +35,4 @@ jobs:
           echo "${{ secrets.KUBECONFIG }}" > ~/.kube/config
           chmod 600 ~/.kube/config
           kubectl rollout restart statefulset/im-server -n im-server-system
-          kubectl rollout status statefulset/im-server -n im-server-system --timeout=120s
+          kubectl rollout status statefulset/im-server -n im-server-system --timeout=300s