Fix typos and improve clarity in documentation files (#120)

This pull request addresses several minor typos and grammatical issues
in multiple documentation files:

1. Fixed incorrect use of "a" instead of "an" in the
"migrations-guidelines.md" file.
2. Corrected the hyphenation of "up to date" in the "pull-requests.md"
file.
3. Corrected the article usage ("a" to "an") in the
"extension-e2e-guidelines.md" file.

These changes enhance the clarity and correctness of the documentation.

Author: Dimitrolito

docs/migrations-guidelines.md

@@ -56,7 +56,7 @@ Completes the migration by returning the state, modified or not, ensuring a seam
 - Always use deep cloning on the old state before passing it to the migration function in tests. For example, use `cloneDeep` from `lodash`.
   - Deep cloning preserves the integrity of your test data across different test cases.
   - Ensures the original state object is not mutated during the migration process.
-  - guarantees that each test case runs on an correct, clean copy of the state.
+  - guarantees that each test case runs on a correct, clean copy of the state.
 - Never mutate the state directly as this can:
   - lead to hard-to-track bugs and false positives or negatives test results.
   - start subsequent tests with the original state as intended.

docs/pull-requests.md

@@ -50,7 +50,7 @@ If there are specific changes within your pull request that you'd like to call y
 
 ### Create smaller pull requests
 
-Large pull requests are extremely painful to review. They also need to be kept up to date more frequently since they have a higher chance of creating conflicts that need to be resolved, and they make the commit history more difficult to understand after they are merged.
+Large pull requests are extremely painful to review. They also need to be kept up-to-date more frequently since they have a higher chance of creating conflicts that need to be resolved, and they make the commit history more difficult to understand after they are merged.
 
 Creating small pull requests starts with creating small issues; break your tasks up into smaller pieces ahead of time whenever possible, to prevent pull requests from growing in size in the first place. If a single task still requires many changes, plan out (or prototype) the code changes that are required, and consider how they can be decomposed into separate changes before marking them as ready for review.
 

docs/testing/e2e/extension-e2e-guidelines.md

@@ -318,7 +318,7 @@ Test Name: Connects to a Hardware wallet for Trezor
 
 ## Page Object Model (POM)
 
-POM, or Page Object Model, is a design pattern commonly utilized for writing automated end-to-end tests. A page object is a instance of a class that acts as an interface for the page of the application under test.
+POM, or Page Object Model, is a design pattern commonly utilized for writing automated end-to-end tests. A page object is an instance of a class that acts as an interface for the page of the application under test.
 This design pattern is being adopted due to its numerous benefits, including improved test maintenance, increased code reusability, and enhanced readability of test scripts. By abstracting the UI details into page objects, changes to the application's UI require updates only in the page objects, significantly reducing the effort needed to maintain tests as the application evolves. The adoption of POM in our e2e testing strategy aims to leverage these advantages to create a more robust, maintainable, and efficient testing framework.
 
 ### Composition of a Page Class