Editorial workflow breaks when Azure backend response lacks PR labels field

**Describe the bug**
The Workflow screen fails to load. It gets stuck in the 'Loading Editorial Workflow Entries' state after showing the error message `Failed to load entry: TypeError: Cannot read properties of undefined (reading 'some')`.

**To Reproduce**
The behavior appears when collaborating through Azure DevOps on a branch with both Decap and non-Decap PRs.

Given a Decap project
* using Azure backend
* configured to use `main` branch
* with Editorial Workflow enabled.

1. In the Azure DevOps UI (not through Decap), create a PR against `main`. (In other words, create a PR against same branch that Decap is also configured for.)
2. Open the Decap project in the browser.
3. Navigate to the Workflow screen (e.g. `/admin/#/workflow`).

After that, you can prevent the buggy behavior by going to the same PR in the Azure DevOps UI, and adding at least one label (content doesn't matter).

**Expected behavior**
The Workflow screen should load and function as intended, regardless of what other PRs are in place

**Screenshots**

**Trace**
```log
API.js:467 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'some')
at API.js:467:24
at Array.filter ()
at t.default.getPullRequests (API.js:466:35)
at async t.default.listUnpublishedBranches (API.js:474:5)
at async t.unpublishedEntries (implementation.js:62:5)
at async t.default.unpublishedEntries (implementation.js:238:5)
at async K.unpublishedEntries (backend.js:755:11)
(anonymous) @ API.js:467
getPullRequests @ API.js:466
Promise.catch (async)
(anonymous) @ editorialWorkflow.js:276
(anonymous) @ index.js:16
n. @ bindActionCreators.js:9
componentDidMount @ Workflow.js:55
…
```

**Applicable Versions:**
- Decap CMS version: 3.0.0
- Git provider: Azure
- OS: MacOS
- Browser version: Chrome 120

**CMS configuration**
```yml
backend:
name: azure
repo: {org}/{project}/{repo}
branch: main
tenant_id: {…}
app_id: {…}

publish_mode: editorial_workflow
```

**Additional context**
The root cause can rightfully be considered a bug in the Azure DevOps REST API. Their [documentation](https://learn.microsoft.com/en-us/rest/api/azure/devops/git/pull-requests/get-pull-requests) indicates that a `labels` field will always be present when listing pull requests. However, that is not the case in practice. In a [support thread](https://developercommunity.visualstudio.com/t/REST-API:-Get-Pull-Requests-By-Project-n/596123#T-N598199), a Microsoft rep indicates that it might actually be intended behavior (pointing to a specific API endpoint for PR labels).

Decap's Azure backend API [implementation](https://github.com/decaporg/decap-cms/blob/6ce52fbd188187ecc82af66458f2da7ad1fd98f7/packages/decap-cms-backend-azure/src/API.ts#L592C2-L592C2) assumes that the returned pr objects will have a `labels` property.

We could change the `getPullRequests` implementation such that the `pullRequests.filter` also works if `pr.labels` is undefined.

I believe it wouldn't hurt to add that improvement, especially since any Azure DevOps API would take time (if it indeed would happen).

Happy to prep a PR if maintainers confirm it makes sense.