fix(labeling guidelines): Add definition of regression-develop label (#…

…23855)

## **Description**

- New  definition added to labelling guidelines: `regression-develop`.
- Same PR on Mobile repo:
MetaMask/metamask-mobile#9142

## **Related issues**

- Fixes: None

## **Manual testing steps**

- None

## **Screenshots/Recordings**

- Preview available here:
https://github.com/MetaMask/metamask-extension/blob/08c910cf750017d0bf586a28578dbfad8d6599c1/.github/guidelines/LABELING_GUIDELINES.md

## **Pre-merge author checklist**

- [x] I’ve followed [MetaMask Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

.github/guidelines/LABELING_GUIDELINES.md

@@ -12,7 +12,8 @@ It's essential to ensure that PRs have the appropriate labels before they are co
 - **release-x.y.z**: This label is automatically added to a PR and its linked issues upon the PR's merge. The `x.y.z` in the label represents the version in which the changes from the PR will be included. This label is auto-generated by a [GitHub action](../workflows/add-release-label.yml), which determines the version by incrementing the minor version number from the most recent release. Manual intervention is only required in specific cases. For instance, if a merged PR is cherry-picked into a release branch, typically done to address Release Candidate (RC) bugs, the label would need to be manually updated to reflect the correct version.
 - **regression-prod-x.y.z**: This label is automatically added to a bug report issue at the time of its creation. The `x.y.z` in the label represents the version in which the bug first appeared. This label is auto-generated by a [GitHub action](../workflows/check-template-and-add-labels.yml), which determines the `x.y.z` value based on the version information provided in the bug report issue form. Manual intervention is only necessary under certain circumstances. For example, if a user submits a bug report and specifies the version they are currently using, but the bug was actually introduced in a prior version, the label would need to be manually updated to accurately reflect the version where the bug originated.
 
-### Optional QA labels:
+### Optional labels:
+- **regression-develop**: This label can manually be added to a bug report issue at the time of its creation if the bug is present on development branch (i.e. `develop`), but is not yet released in production.
 - **needs-qa**: If the PR includes a new features, complex testing steps, or large refactors, this label must be added to indicated PR requires a full manual QA prior being merged and added to a release.
 
 ### Labels prohibited when PR needs to be merged: