ci: make prettier happy

Signed-off-by: Tomás Migone <[email protected]>

Author: tmigone

website/src/pages/en/graph-horizon/migration-guide.mdx

@@ -15,11 +15,7 @@ The Graph Horizon upgrade has been designed to minimize disruption across the ne
 
 The upgrade involves updating indexer software components and infrastructure to be compatible with the new Horizon architecture.
 
-🚨 **Important**: Graph Horizon is a breaking change to the
-protocol. Indexers who do not upgrade will eventually lose access
-to indexing rewards and query fees. Existing allocations opened
-before Graph Horizon will continue to accrue rewards and fees, but
-non-upgraded indexers will be unable to open new allocations.
+🚨 **Important**: Graph Horizon is a breaking change to the protocol. Indexers who do not upgrade will eventually lose access to indexing rewards and query fees. Existing allocations opened before Graph Horizon will continue to accrue rewards and fees, but non-upgraded indexers will be unable to open new allocations.
 
 For detailed upgrade instructions, see the [Indexer Upgrade Guide](https://www.notion.so/edgeandnode/Graph-Horizon-indexer-stack-upgrade-guide-2658686fc7c2808984fbcc55e535e3b2?source=copy_link).
 
@@ -44,5 +40,6 @@ Applications querying subgraphs will experience no disruption. The upgrade is de
 ## Support
 
 If you have questions about the upgrade process please reach out:
+
 - [The Graph Discord](https://discord.gg/graphprotocol)
 - [The Graph Forum](https://forum.thegraph.com/)

website/src/pages/en/graph-horizon/overview.mdx

@@ -4,6 +4,7 @@ sidebarTitle: Overview
 ---
 
 This document provides a high level overview of Graph Horizon. For a deep dive the following GIPs are recommended:
+
 - [GIP-0066: Introducing Graph Horizon - A data services protocol](https://github.com/graphprotocol/graph-improvement-proposals/blob/3da23cbba56fbd211de61f08c60b8c3e93ba5bc5/gips/0066-graph-horizon.md)
 - [GIP-0068: Subgraph Service - A subgraph data service in Graph Horizon](https://github.com/graphprotocol/graph-improvement-proposals/blob/3da23cbba56fbd211de61f08c60b8c3e93ba5bc5/gips/0068-subgraph-service.md)
 - [GIP-0085: Graph Horizon: Arbitration Charter](https://github.com/graphprotocol/graph-improvement-proposals/blob/3da23cbba56fbd211de61f08c60b8c3e93ba5bc5/gips/0085-horizon-arbitration-charter.md)
@@ -40,7 +41,7 @@ The **`SubgraphService`** is the first and currently only data service implement
 
 ### Integrated Payments Protocol
 
-While the current protocol uses TAP (Timeline Aggregation Protocol) for payments, Horizon brings the payments infrastructure directly into the core protocol. The payments protocol in Horizon was designed as a generalized version of TAP v1, allowing integration with TAPv2 (GraphTally) but also any other arbitrary payment collection system. 
+While the current protocol uses TAP (Timeline Aggregation Protocol) for payments, Horizon brings the payments infrastructure directly into the core protocol. The payments protocol in Horizon was designed as a generalized version of TAP v1, allowing integration with TAPv2 (GraphTally) but also any other arbitrary payment collection system.
 
 ### GraphPayments and PaymentsEscrow
 

website/src/pages/en/graph-horizon/what-changes.mdx

@@ -45,15 +45,15 @@ Horizon does not change the way indexing rewards work, the rewards formula remai
 The indexer stack will support both the current and Horizon gateway infrastructure, which means with the same indexer stack version indexers will be able to serve queries before and after the Horizon upgrade. It’s worth clarifying however the gateway behavior:
 
 - Before Horizon, the gateway will serve queries using TAPv1 receipts.
-- After Horizon, the gateway will *only* serve queries using TAPv2 (GraphTally) receipts. This means that indexers that have not upgraded their stack to Horizon will stop receiving queries. The gateway infrastructure will continue to accept old TAPv1 receipts and vouchers to ensure those can be redeemed and no fees are lost.
+- After Horizon, the gateway will _only_ serve queries using TAPv2 (GraphTally) receipts. This means that indexers that have not upgraded their stack to Horizon will stop receiving queries. The gateway infrastructure will continue to accept old TAPv1 receipts and vouchers to ensure those can be redeemed and no fees are lost.
 
 ## For Delegators
 
 ### Per Data-Service Delegation
 
 Delegation is now more specific - delegators must choose both an indexer AND a data service to delegate to. This gives delegators more control and ensures their stake is only used for services they've explicitly approved. Existing delegations will automatically migrate to the `SubgraphService`.
 
-For practical purposes, The Graph's user interfaces will only support delegation to the `SubgraphService`. While Horizon's architecture allows delegation to other data services, supporting them would require UI changes or new interfaces. In the future as new data services emerge new user interfaces will likely do so, or existing ones will be upgraded to support them. 
+For practical purposes, The Graph's user interfaces will only support delegation to the `SubgraphService`. While Horizon's architecture allows delegation to other data services, supporting them would require UI changes or new interfaces. In the future as new data services emerge new user interfaces will likely do so, or existing ones will be upgraded to support them.
 
 ### Potential Future Slashability
 
@@ -67,7 +67,7 @@ The 0.5% delegation tax has been completely removed, making it more economical f
 
 ### Multiple Undelegation Requests
 
-Delegators can now have multiple undelegation requests processing simultaneously (up to 100), providing more flexibility in managing their stake. 
+Delegators can now have multiple undelegation requests processing simultaneously (up to 100), providing more flexibility in managing their stake.
 
 ## Changes to Slashing
 
@@ -85,4 +85,4 @@ While Horizon brings significant improvements, several core elements remain unch
 
 - **Curation mechanism**: The way subgraphs are signaled and curated remains the same
 - **Indexing rewards formula**: The calculation and distribution of indexing rewards follows the same formula
-- **GRT token**: The Graph Token (GRT) remains unchanged
+- **GRT token**: The Graph Token (GRT) remains unchanged