chore: fix prettier formatting

docs/guides/batching.md

@@ -93,7 +93,6 @@ In the push model: when the operation is complete, the server pushes the results
 
 URL style #6 in the table above, uses a `Content-type` of `multipart/mixed` which makes it the most flexible way of implementing batching in REST APIs. It allows clients to submit arbitrary operations (multiple _Create_, _Read_, _Update_, and _Delete_ operations, each with its own `Content-type`) in a single request, though most services enforce a limit[^batch-size-limit] in the range of 10-1000 called the batch size. The batch size is the number of sub-requests that can be included in a single request to an endpoint that supports batching.
 
-
 ---
 
 ## Batching in Tailcall
@@ -148,8 +147,6 @@ In our example above, I enabled HTTP caching by setting the [`httpCache`](https:
 
 I also configured [`batch`](https://tailcall.run/docs/operators/upstream/#batch) object which controls batching. I set `delay: 1` indicating a delay of 1 millisecond between each batch request (to avoid getting throttled by the upstream server) and set `maxSize: 100` indicating the Tailcall can issue up to `100` sub-requests as part of a single batch request.
 
-
-
 When you run the following GraphQL query:
 
 ```graphql
@@ -186,7 +183,6 @@ The `/users` endpoint returns a total of 30 users. As you can see in the output,
 
 Batching is an optimization technique for mitigating the [N+1 problem](https://tailcall.run/docs/guides/n+1/) as it can significantly reduce the number of network round-trips needed to fulfil a request when one or more upstream servers are involved.
 
-
 [^1]: To take full advantage of batching, the REST backends being proxied with Tailcall must themselves have support for batching i.e. they must support the ability to combine multiple individual requests into a single request.
 [^delivery]: https://news.ycombinator.com/item?id=28392042
 [^202-Accepted]: https://www.mscharhag.com/api-design/bulk-and-batch-operations