docs: update /services/indexer to /indexer (#3189)

docs/pages/introduction.mdx

@@ -8,7 +8,7 @@ MUD is a framework for ambitious onchain applications. It reduces the complexity
 
 Writing smart contracts is only a small part of building user-friendly EVM apps. Your frontend needs get data from the chain. You've kept your onchain logic simple to save users gas, but now getting data from the RPC is tricky and slow. So you spin up an indexer, write event handlers, and teach your frontend how to talk to another backend. Complicated, right?
 
-MUD provides much of this out of the box. It uses a [familiar data model](/store/data-model) with tables and fields, built on a standardized storage protocol. This lets us provide you with an [automatic indexer](/services/indexer), no code is necessary to use it. And because it's all standardized, our client libraries already know how to get your app's onchain state and keep your frontend in sync with the chain.
+MUD provides much of this out of the box. It uses a [familiar data model](/store/data-model) with tables and fields, built on a standardized storage protocol. This lets us provide you with an [automatic indexer](/indexer), no code is necessary to use it. And because it's all standardized, our client libraries already know how to get your app's onchain state and keep your frontend in sync with the chain.
 
 MUD apps are [autonomous worlds](https://0xparc.org/blog/autonomous-worlds), infinitely extendable by default. They come with access control, upgradability, hooks, plugins, and a suite of great developer tools.
 

docs/pages/store/introduction.mdx

@@ -1,7 +1,7 @@
 # Introduction
 
 `Store` is an alternative to Solidity's storage engine.
-It enforces a data model that can be mapped directly to a relational database, enables [automatic indexing](../services/indexer) by emitting a common set of events for each mutation, and [packs data more tightly](./encoding) than native Solidity.
+It enforces a data model that can be mapped directly to a relational database, enables [automatic indexing](../indexer) by emitting a common set of events for each mutation, and [packs data more tightly](./encoding) than native Solidity.
 It also allows external contract storage to be read onchain without being limited by existing `view` functions and [without a new opcode](https://eips.ethereum.org/EIPS/eip-2330).
 
 ## Data model
@@ -42,4 +42,4 @@ This allows advanced use cases like the [`World` protocol](../world/introduction
 ## Automatic indexing
 
 `Store` automatically emits events on every write operation, including when a new table is registered in the `Store` at runtime.
-These events allow [automatic indexers](../services/indexer) to [replicate the onchain state](/guides/replicating-onchain-state) of each table in each `Store` contract in a relational database for offchain use, without the need for custom integrations.
+These events allow [automatic indexers](../indexer) to [replicate the onchain state](/guides/replicating-onchain-state) of each table in each `Store` contract in a relational database for offchain use, without the need for custom integrations.

docs/pages/store/tables.mdx

@@ -14,7 +14,7 @@ You can think of tables in two ways, either [as a relational database](./data-mo
 
 Tables are registered in the `Store` contract at runtime.
 When a table is registered, its ID, key and value types, as well as key and field names are stored in the internal `Tables` table.
-This emits an event that can be used by [offchain indexers](../services/indexer) to start [replicating the state](/guides/replicating-onchain-state) of the new table.
+This emits an event that can be used by [offchain indexers](../indexer) to start [replicating the state](/guides/replicating-onchain-state) of the new table.
 
 The recommended way of reading from tables and writing to tables is via the [typed table libraries](./table-libraries).
 However, it is also possible to use the low-level [`IStore` (external)](./reference/store) or [`StoreCore` (internal)](./reference/store-core) API directly.
@@ -27,10 +27,10 @@ There are two types of tables in `Store`: _Onchain tables_ and _offchain tables_
 We often omit the prefix from onchain tables and just call them tables.
 
 As the name suggests, **onchain tables** store their state onchain, in the `Store` contract.
-In addition, an event is emitted on every write operation, to allow [offchain indexers](../services/indexer) to [replicate the onchain state](/guides/replicating-onchain-state).
+In addition, an event is emitted on every write operation, to allow [offchain indexers](../indexer) to [replicate the onchain state](/guides/replicating-onchain-state).
 
-**Offchain tables** on the other hand don't store any state onchain, but only emit the events for [offchain indexers](../services/indexer).
-This makes them suitable for use cases where data doesn't need to be retrieved onchain, but should still be synchronized from the `Store` contract to [offchain indexers](../services/indexer).
+**Offchain tables** on the other hand don't store any state onchain, but only emit the events for [offchain indexers](../indexer).
+This makes them suitable for use cases where data doesn't need to be retrieved onchain, but should still be synchronized from the `Store` contract to [offchain indexers](../indexer).
 
 Onchain you can write to offchain tables with the same methods as onchain tables, except for reading data and modifying partial data in a dynamic field.
 
@@ -71,7 +71,7 @@ Tables have two schemas, one for the key and the other for the values.
 #### Key schema
 
 The key schema represents the data types of the (composite) key of the table.
-Internally the composite key is always handled as `bytes32[]`, but the key schema allows [offchain indexers](../services/indexer) to create properly typed composite key columns, and allows MUD to generate [typed table libraries](./table-libraries).
+Internally the composite key is always handled as `bytes32[]`, but the key schema allows [offchain indexers](../indexer) to create properly typed composite key columns, and allows MUD to generate [typed table libraries](./table-libraries).
 
 The key schema can contain up to 28 static (fixed length) data types.
 Note that no dynamic (variable length) data types (e.g. arrays, `bytes` or `string`) are supported in the key schema.
@@ -89,7 +89,7 @@ Schema keySchema = SchemaLib.encode(keySchemaTypes);
 #### Value schema
 
 The value schema represents the data types of the value fields of the table.
-Similar to key schemas, it allows [offchain indexers](../services/indexer) to create properly typed value columns, and allows MUD to generate [typed table libraries](./table-libraries).
+Similar to key schemas, it allows [offchain indexers](../indexer) to create properly typed value columns, and allows MUD to generate [typed table libraries](./table-libraries).
 
 The value schema can contain up to 28 fields in total, of which up to 5 can be dynamic (variable length) data types (e.g. arrays, `bytes`, `string`).
 All static (fixed length) data types must come before the dynamic data types.
@@ -131,7 +131,7 @@ FieldLayout fieldLayout = FieldLayoutLib.encode(staticFields, 0);
 
 ### Manually register a table
 
-Registering a table is a prerequisite for writing to the table, and allows [offchain indexers](../services/indexer) to [replicate the onchain state](/guides/replicating-onchain-state).
+Registering a table is a prerequisite for writing to the table, and allows [offchain indexers](../indexer) to [replicate the onchain state](/guides/replicating-onchain-state).
 
 ```solidity copy
 import { IStore } from "@latticexyz/store/src/IStore.sol";

docs/pages/world/resource-ids.mdx

@@ -8,9 +8,9 @@ It is two bytes of resource type followed by 14 bytes of namespace and then 16 b
 Currently, MUD supports these resource types:
 
 - [Table (`tb`)](https://github.com/latticexyz/mud/blob/main/packages/store/src/storeResourceTypes.sol#L12).
-  An onchain table whose information is available both onchain (through calls to `view` functions) and offchain (either through calls to `view` functions, events, or an [indexer](/services/indexer)).
+  An onchain table whose information is available both onchain (through calls to `view` functions) and offchain (either through calls to `view` functions, events, or an [indexer](/indexer)).
 - [Offchain table (`ot`)](https://github.com/latticexyz/mud/blob/main/packages/store/src/storeResourceTypes.sol#L15).
-  An offchain table whose information is only available offchain (either through events, or through an [indexer](/services/indexer)).
+  An offchain table whose information is only available offchain (either through events, or through an [indexer](/indexer)).
 - [Namespace (`ns`)](https://github.com/latticexyz/mud/blob/main/packages/world/src/worldResourceTypes.sol#L13).
   A namespace is a container for tables, offchain tables, and systems.
   Namespaces are used for [access control](/world/namespaces-access-control).