chore: remove redundant words (#476)

Signed-off-by: avoidaway <[email protected]>
Co-authored-by: Mark Tyneway <[email protected]>

meta/OP Mainnet: release flow explained (high-level overview).md

@@ -207,7 +207,7 @@ Note that governance proposals are *all-or-nothing:* if one aspect of the propos
 
 Format and share your governance post using the official [Standard Proposal Template](https://gov.optimism.io/t/standard-proposal-template-optimism-token-house/5443). 
 
-Use the the [Canyon](https://gov.optimism.io/t/final-upgrade-proposal-2-canyon-network-upgrade/7088) / [Delta](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310)  or [Ecotone](https://gov.optimism.io/t/upgrade-proposal-5-ecotone-network-upgrade/7669) governance posts as guides for what to say.
+Use the [Canyon](https://gov.optimism.io/t/final-upgrade-proposal-2-canyon-network-upgrade/7088) / [Delta](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310)  or [Ecotone](https://gov.optimism.io/t/upgrade-proposal-5-ecotone-network-upgrade/7669) governance posts as guides for what to say.
 
 Some useful tips for writing your governance post:
 

specs/protocol/fjord/derivation.md

@@ -66,7 +66,7 @@ The rules around the activation time are deliberately being kept simple, so no o
 be applied other than to change the parameter to a constant. The first Fjord block would in theory
 accept older L1-origin timestamps than its predecessor. However, since the L1 origin timestamp must
 also increase, the only noteworthy scenario that can happen is that the first few Fjord blocks will
-be in the same epoch as the the last pre-Fjord blocks, even if these blocks would not be allowed to
+be in the same epoch as the last pre-Fjord blocks, even if these blocks would not be allowed to
 have these L1-origin timestamps according to pre-Fjord rules. So the same L1 timestamp would be
 shared within a pre- and post-Fjord mixed epoch. This is considered a feature and is not considered
 a security issue.

specs/protocol/safe-extensions.md

@@ -107,7 +107,7 @@ The following security properties must be upheld by the `DeputyGuardianModule`:
 1. The module must not be able to cause the Safe to make calls to functions which the Guardian role
    is not authorized to make.
 1. The module must be safely removable.
-1. The module must not introduce any possibility of disabling the the Safe so that it can no longer
+1. The module must not introduce any possibility of disabling the Safe so that it can no longer
    forward transactions.
 1. The module must format calldata correctly such that the target it calls performs the expected
    action.