docs: fix duplicate 'the' typos in spammer README and base-fee ADR

Two small duplicate-word typos in documentation:

- crates/spammer/README.md: 'the the transaction' -> 'the transaction'
- docs/adr/0004-base-fee-validation.md: 'the the header' -> 'in the header'

For the ADR typo, 'in' reads naturally in context:
'Arc includes the next block base fee in the header, computed at
the end of the parent's block execution'

Happy to adjust phrasing if a different reading was intended.

Author: Sertug17

crates/spammer/README.md

@@ -391,7 +391,7 @@ a finalized block.
 The latency tracker records the time between:
 
 1. **Submission**: when the spammer sends the transaction to the RPC endpoint of a node
-2. **Finalization**: the block in which the the transaction was included is known to be finalized, via a RPC subscription
+2. **Finalization**: the block in which the transaction was included is known to be finalized, via a RPC subscription
 observes.
 
 This measures end-to-end transaction latency as experienced by a client.

docs/adr/0004-base-fee-validation.md

@@ -15,7 +15,7 @@ On Arc, the base fee calculation combines: 1) an EIP-1559-style algorithm, 2)  s
 
 The value of 1) is that it is familiar and well-understood. The value of 2) is to enable rapid adjusting of fee parameters and strictly enforcing block gas limits through governance. The value of 3) is to dampen fee increases against sudden shocks in usage with Arc's fast blocktimes.
 
-The combination of these makes it challenging for integrators to precisely understand the next block base fee as the calculation is more involved. To address this, Arc includes the next block base fee the the header, computed at the end of the parent's block execution, since it is fully known at that point. 
+The combination of these makes it challenging for integrators to precisely understand the next block base fee as the calculation is more involved. To address this, Arc includes the next block base fee in the header, computed at the end of the parent's block execution, since it is fully known at that point. 
 
 Currently, the implementation has several gaps in validation. This ADR, similar to ADR-003, seeks to document solutions to these gaps.