Website: compress large gifs and update article image filenames (#26328)

Changes:
- Compressed large gifs to prevent the website's slug size from going
over 500mb
- Updated image filenames added in #26316 to match website naming
conventions.

articles/articles/preventing-mistakes-with-gitops.md

@@ -40,23 +40,23 @@ We will start with a traditional workflow to demonstrate the process used to com
 
 > For all examples in this article we will be using the GitHub Desktop app to do commits. Using `git` in the terminal will of course also work. Use whatever you’re most comfortable with.
 
-![gif-1](../website/assets/images/articles/preventing-mistakes-1.gif)
+![gif-1](../website/assets/images/articles/preventing-mistakes-1-1423x771@2x.gif)
 
 Here, after making changes to the `passcode.json` file, it has been added to the Team we are configuring under the `macos_settings` section.
 
-![gif-2](../website/assets/images/articles/preventing-mistakes-2.gif)
+![gif-2](../website/assets/images/articles/preventing-mistakes-2-960x540@2x.gif)
 
 GitHub Desktop will automatically pick up changes. You can review each file and make commit comments. If all looks good, push your changes to the working branch.
 
-![gif-3](../website/assets/images/articles/preventing-mistakes-3.gif)
+![gif-3](../website/assets/images/articles/preventing-mistakes-3-1423x771@2x.gif)
 
 We create a PR to bring this change into the `main` production branch. In this example, branch protections are off so I can merge right to `main` but further on in the article this will change. 
 
 ## GitOps: The way it was meant to be
 
 Another benefit of a GitOps approach is the ability for members of a team to review changes before they are applied in production. This encourages collaboration while ensuring all modifications to state are following best practices and compliance. In addition, if something breaks (which is inevitable) you have a ‘snapshot’ or point in time with a known working state to which you can easily roll back.
 
-![gif-4](../website/assets/images/articles/preventing-mistakes-4.gif)
+![gif-4](../website/assets/images/articles/preventing-mistakes-4-960x540@2x.gif)
 
 The newest version of macOS is released and an engineer on your team wants to push a change to require an update of all hosts in the Workstations team. The IT engineer creates a branch to work from and makes the necessary changes, including setting a new target version and deadline.
 
@@ -68,15 +68,15 @@ macos_updates:
 
 Merging is blocked until a member of the team reviews and approves the changes. 
 
-![gif-5](../website/assets/images/articles/preventing-mistakes-5.gif)
+![gif-5](../website/assets/images/articles/preventing-mistakes-5-960x540@2x.gif)
 
 Our IT manager is listed as the approver for these changes. The approver is notified of a pending PR for review. Is there a problem with some of the changes? Our engineer accidentally put in a version string that is not yet available. This will cause issues for our users when they try to update. The fix? Tag the engineer with some feedback and request changes to be made and re-committed. 
 
-![Pr Approval](../website/assets/images/articles/pr-approval.jpg)
+![Pr Approval](../website/assets/images/articles/pr-approval-921x475@2x.jpg)
 
 After our engineer has updated code from the review, the approver can do a final review, approve and let the engineer merge this branch into `main` to trigger the apply workflow. This will push the changes into the production environment. ✨
 
-![Pr Approval](../website/assets/images/articles/pr-approval-2.jpg)
+![Pr Approval](../website/assets/images/articles/pr-approval-2-933x483@2x.jpg)
 
 ## Conclusion