PNW-2730 - updated logic to handle empty label use case

[dfdez]

ℹ️ What's this PR do?

This PR introduces a self-healing mechanism to the editorial workflow to handle cases where a Pull Request fails to get labeled upon creation, making it more resilient. It also includes a fix for the entry deletion process.

• Proactive PR Labeling: Implements a new getCmsRefs function in API.ts that fetches all open PRs matching the CMS branch prefix. If a PR is found without a CMS status label, it automatically applies the default initialWorkflowStatus, ensuring no entry becomes "invisible" to the workflow.
• Resilient Stack Handling: Adds a getStackLabel helper to ensure the stack's PR always has a valid status label, applying one on-the-fly if it's missing to prevent processing errors.
• Fix Delete Workflow: Corrects the logic in editorialWorkflow.ts and entries.ts to properly pass the customEntry context during unpublishing/deletion operations.

---

👀 Where should the reviewer start?

• packages/decap-cms-backend-github/src/API.ts: Review the new getCmsRefs and getStackLabel functions, which contain the core logic for the self-healing mechanism.
• packages/decap-cms-core/src/actions/editorialWorkflow.ts: Inspect the changes for the delete entry workflow fix.
• packages/decap-cms-core/src/actions/entries.ts: Review the related context-passing fix for entry deletion.

---

📱 How should this be tested?

As reviewer, remember you always have to test the code locally on your machine. To do so follow these instructions:

1. Checkout the PR branch
2. Build your packages if necessary with npm run build

In order to test the library in a local project, you need to execute npm link. Follow the instruction from the documentation in order to setup the development environment.

On landings-cms checkout to feat/PNW-2730_label-missing-improvements to make all the following tests

• Test Case 1: Unlabeled PR Recovery

  1. Create a new entry in the CMS and let it create a PR.
  2. Quickly go to the PR on GitHub and manually remove the netlify-cms/draft label before the CMS polls again.
  3. Return to the CMS workflow UI.
  4. Verify that after a short time, the entry correctly appears in the workflow, and the label has been re-applied to the PR on GitHub.

• Test Case 2: Standard Workflow (Regression Test)

  1. Create, update, and publish a new entry.
  2. Verify that the entire process works smoothly without any new issues.

• Test Case 3: Delete/Unpublish Workflow

  1. Select a published entry that can be unpublished.
  2. Use the "Unpublish" action in the CMS.
  3. Verify that the process completes successfully and the entry is correctly removed or moved to the workflow.

---

🤔 Any background context you want to provide?

Problem: Occasionally, the GitHub API fails to apply a status label (e.g., netlify-cms/draft) to a newly created PR. This makes the PR "invisible" to the CMS, blocking the user from viewing, editing, or publishing their changes via the editorial workflow.

Solution: This PR refactors the GitHub backend to be resilient to this failure. Instead of only fetching PRs that are already labeled, the backend now fetches all relevant open PRs, identifies any without a CMS label, and automatically applies the default initial status. This creates a self-healing system that ensures every entry is correctly tracked.

This work is based on the technical study from PNW-2728.

[dfdez]

This is not directly related with the PR just a fix on deleteEntry workflow which currently is not working properly