Fix update-schedule workflow: rename branch, add proper error handling

[Caesarsage]

The workflow has been silently failing because the stale remote branch "update-schedule" could not be force-pushed to, preventing PR creation.

Changes:

• Rename PR branch from "update-schedule" to "auto/update-schedule"
• Delete stale remote branch before creating PR to prevent push failures
• Fix retry loop to properly fail the job after 3 attempts
• Remove unnecessary fetch-depth: 0

I tried this on my own branch to confirm work flow works which created this : Caesarsage#2

my debug/test changes:
Caesarsage@201909b

closes #54940

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign reylejano for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• .github/workflows/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	6124ca3
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-io-main-staging/deploys/69b89dc7c83bf100087593b5
😎 Deploy Preview	https://deploy-preview-54932--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lmktfy]

This really needs an issue filed.

Also: before making any update, we ought to make sure that we know why the existing workflow is changing.

[lmktfy]

I expect that using a different branch name might fail due to rules on branch protection.

[Caesarsage]

I expect that using a different branch name might fail due to rules on branch protection.

Okay, I didn't think about that. Another way would be to delete the stale update-schedule branch. The workflow should then work as-is on the next run. We could then add a step to the action to always delete the stale PR branch before creating a new one, to prevent this from happening again.