Stop overriding escalated label

What does this MR do and why?

Fix 3 bugs related to master broken incident labeling:

1. in gitlab-org/quality/engineering-productivity/master-broken-incidents#8873 (closed), an already escalated incident still received the ~escalation::skipped label. Expected behaviour: we should never override escalation::escalated.
2. in gitlab-org/quality/engineering-productivity/master-broken-incidents#8848 (closed), an already closed incident received the escalation::skipped label. Expected behaviour: closed incidents should not receive any escalation label update
3. Still in gitlab-org/quality/engineering-productivity/master-broken-incidents#8848 (closed), the incident was originally labelled with escalation::escalated via the /copy_metadata command when it was marked as duplicate. Expected behaviour: we don't want to label an incident with escalation::escalated when it's being closed as a duplicate. Note: We can fix this issue by removing the /copy_metadata command from the incident_modifier_comment method. I think this is totally fine because we have a scheduled automation to revisit these closed incidents and apply root cause label on the next day

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review