docs: fix duplicate "the" typos in spammer README and base fee ADR (#73)

## Summary

Two small duplicate-word typos in documentation:

1. **`crates/spammer/README.md:394`** — `the the transaction` → `the
transaction`
2. **`docs/adr/0004-base-fee-validation.md:18`** — `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 change to a different phrasing if a different reading was
intended (e.g., simply removing the extra "the" → "...base fee the
header...", or "...to the header...").

## Change

```diff
diff --git a/crates/spammer/README.md b/crates/spammer/README.md
@@ -394 +394 @@
-2. **Finalization**: the block in which the the transaction was included...
+2. **Finalization**: the block in which the transaction was included...

diff --git a/docs/adr/0004-base-fee-validation.md b/docs/adr/0004-base-fee-validation.md
@@ -18 +18 @@
-...Arc includes the next block base fee the the header, computed...
+...Arc includes the next block base fee in the header, computed...
```

## Verification

After the change, `grep -rn "the the" --include="*.md" .` returns no
matches in the repo.

## Notes

This is a documentation-only change (2 files, +2/-2).

Author: ZhiyuCircle

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.