Bitbucket Editorial Workflow: Fails to Load Draft - Uses Destination Branch Commit SHA Instead of Source Branch SHA, Leading to 404

**Bug Description:**

When using Decap CMS with the Bitbucket backend and `publish_mode: editorial_workflow`, there's an issue when attempting to load or edit a newly created draft. The CMS initially tries to fetch the draft's file content using the commit SHA of the *destination* branch (e.g., `dev`) of the pull request, instead of the commit SHA of the *source* branch (the feature branch created for the draft, e.g., `cms/collection/slug`). This results in a 404 "No such file or directory" error because the file doesn't exist at that commit on the destination branch yet.

While the CMS sometimes later makes a successful request using the correct source branch commit SHA, the initial failure often leads to the draft being uneditable, disappearing from the workflow UI after a refresh, or showing errors.

**Steps to Reproduce:**

1. Configure Decap CMS with a Bitbucket backend, ensuring `publish_mode: editorial_workflow` is enabled.
2. Set a `backend.branch` (e.g., `dev`) as the target for pull requests.
3. Navigate to a collection in the CMS and create a "New Post" (or new entry for any collection).
4. Fill in the required fields and save the draft. The CMS will create a new branch (e.g., `cms/my-collection/my-new-entry`) and open a pull request to the target branch.
5. The new entry will appear in the "Drafts" column of the Editorial Workflow.
6. Attempt to click on this new draft to open it for editing, or try to drag it to the "In Review" status.
7. Observe the error {"type":"error","error":{"message":"No such file or directory:...}.
8. Manually refresh the workflow page
9. Observe no drafts at all.

**Expected Behavior:**

When opening a draft for editing or changing its status, Decap CMS should fetch the file content by referencing the commit SHA of the **source branch** of the associated pull request. For example, if the pull request is from `cms/my-collection/my-new-entry` (source) to `dev` (destination), the file should be fetched using the latest commit SHA from `cms/my-collection/my-new-entry`.

**Actual Behavior:**

1. Upon attempting to open/edit the draft, Decap CMS makes an initial `GET` request to the Bitbucket API to fetch the file content.
2. This `GET` request incorrectly uses the commit SHA of the **destination branch** (e.g., `dev`) in the API URL for fetching the file source.
* Example failing request URL: `https://api.bitbucket.org/2.0/repositories/YOUR_ORG/YOUR_REPO/src/DESTINATION_BRANCH_COMMIT_SHA/path/to/your/file.md`
3. This request results in a 404 "No such file or directory" error from the Bitbucket API, as the file has not yet been merged into the destination branch.
4. The CMS UI then fails to load the draft, may show an error, or the draft might disappear from the workflow after a page refresh.
5. Sometimes, subsequent network requests (perhaps triggered by other UI interactions or internal retries) *do* use the correct **source branch commit SHA**, and the file is fetched successfully. However, the initial failure often disrupts the user experience.

**Evidence:**

A prior `GET` request to the Bitbucket Pull Requests API correctly retrieves information about the open pull request, including *both* the source and destination commit SHAs:

* **Request URL for PR details:**
`https://api.bitbucket.org/2.0/repositories/YOUR_ORG/YOUR_REPO/pullrequests?pagelen=50&q=source.repository.full_name%20%3D%20%22YOUR_ORG%2FYOUR_REPO%22%20AND%20state%20%3D%20%22OPEN%22%20AND%20destination.branch.name%20%3D%20%22dev%22%20AND%20comment_count%20%3E%200%20AND%20source.branch.name%20%3D%20%22cms%2FCOLLECTION_NAME%2FSLUG%22`
* **Key parts of the PR API Response:**
```json
{
"values": [
{
// ... other PR details
"destination": {
"branch": { "name": "dev" },
"commit": { "hash": "DESTINATION_BRANCH_COMMIT_SHA" } // e.g., 984c47310ea9
},
"source": {
"branch": { "name": "cms/COLLECTION_NAME/SLUG" },
"commit": { "hash": "SOURCE_BRANCH_COMMIT_SHA" } // e.g., 2b82f4b87899
}
}
]
}
```
The issue is that the Decap CMS Bitbucket backend appears to initially use `DESTINATION_BRANCH_COMMIT_SHA` instead of `SOURCE_BRANCH_COMMIT_SHA` when attempting to read the file for the workflow UI.

**Environment:**

* **Decap CMS Version:** \[V3.6.3]
* **Git Provider:** Bitbucket (Cloud)
* **Browser:** \[Brave]
* **OS:** \[macOS]
* **Node.js Version (if applicable):** \[18]
* **`config.yml` snippet for `backend`:**
```yaml
backend:
name: bitbucket
repo: YOUR_ORG/YOUR_REPO
branch: dev # Or your main/target branch
auth_type: implicit # Or your auth type
app_id: YOUR_APP_ID # If using implicit auth

publish_mode: editorial_workflow

media_folder: "static/img" # Example
public_folder: "/img" # Example

collections:
- name: "my-collection"
label: "My Collection"
folder: "content/my-collection" # Example folder
create: true
slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
fields:
- {label: "Title", name: "title", widget: "string"}
- {label: "Body", name: "body", widget: "markdown"}
```

**Additional Context:**

This behavior makes the editorial workflow unreliable with Bitbucket. The necessary data (correct source commit SHA) is available to the CMS via the pull request API response, but it seems to be a logic error in how it's utilized for fetching draft content.