Docs: Unify usage of "Pick into ..." labels

See also
https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/50135

doc/development/contributing/issue_workflow.md

@@ -264,7 +264,7 @@ release. There are three levels of Release Scoping labels:
   milestone. If these issues are not done in the current release, they will
   strongly be considered for the next release.
 - ~"Next Patch Release": Issues to put in the next patch release. Work on these
-  first, and add the "Pick Into X" label to the merge request, along with the
+  first, and add the `~"Pick into X.Y"` label to the merge request, along with the
   appropriate milestone.
 
 Each issue scheduled for the current milestone should be labeled ~Deliverable

doc/development/documentation/index.md

@@ -183,7 +183,7 @@ in a follow-up MR or issue.
 
 NOTE: **Note:**
 If the release version you want to add the documentation to has already been
-frozen or released, use the label `Pick into X.Y` to get it merged into
+frozen or released, use the label `~"Pick into X.Y"` to get it merged into
 the correct release. Avoid picking into a past release as much as you can, as
 it increases the work of the release managers.
 
@@ -203,7 +203,7 @@ to the MR.
 For example, let's say your merge request has a milestone set to 11.3, which
 will be released on 2018-09-22. If it gets merged on 2018-09-15, it will be
 available online on 2018-09-15, but, as the feature freeze date has passed, if
-the MR does not have a "pick into 11.3" label, the milestone has to be changed
+the MR does not have a `~"Pick into 11.3"` label, the milestone has to be changed
 to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
 with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
 11.4 onward, but available on <https://docs.gitlab.com/> on the same day it was merged.

doc/development/feature_flags/controls.md

@@ -192,7 +192,7 @@ feature flag. This ensures the change is available to all users and self-managed
 instances. Make sure to add the ~"feature flag" label to this merge request so
 release managers are aware the changes are hidden behind a feature flag. If the
 merge request has to be picked into a stable branch, make sure to also add the
-appropriate "Pick into X" label (e.g. "Pick into XX.X").
+appropriate `~"Pick into X.Y"` label (e.g. `~"Pick into 13.0"`).
 See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details.
 
 When a feature gate has been removed from the code base, the feature