docs: fix broken links (#3173)

Update links

docs/source/entities/contribute-fields.mdx

@@ -35,7 +35,7 @@ By default, each subgraph must contribute different fields, with the important e
 If multiple subgraphs attempt to contribute the same field, a composition error occurs.
 To override this default behavior, see [Resolving another subgraph's field](/graphos/schema-design/federated-schemas/entities/resolve-another-subgraphs-fields).
 
-Each subgraph that contributes fields to an entity must [define a reference resolver](/graphos/get-started/guides/federate-schemas/#2-define-a-reference-resolver) for that entity.
+Each subgraph that contributes fields to an entity must [define a reference resolver](/graphos/schema-design/federated-schemas/entities/intro/#2-define-a-reference-resolver) for that entity.
 
 ## Contributing computed entity fields
 

docs/source/entities/handling-n-plus-one.mdx

@@ -163,7 +163,7 @@ QueryPlan {
 </ExpansionPanel>
 
 Most subgraph implementations (including [`@apollo/subgraph`](/apollo-server/using-federation/api/apollo-subgraph/)) don't write the [`Query._entities` resolver](/graphos/reference/federation/subgraph-specific-fields/#query_entities) directly.
-Instead, they use the [reference resolver API](/graphos/get-started/guides/federate-schemas/#2-define-a-reference-resolver) for resolving an individual entity reference:
+Instead, they use the [reference resolver API](/graphos/schema-design/federated-schemas/entities/intro/#2-define-a-reference-resolver) for resolving an individual entity reference:
 
 ```js
 const resolvers = {

docs/source/federated-schemas/federated-directives.mdx

@@ -185,7 +185,7 @@ See also [Advanced `@key`s](/graphos/schema-design/federated-schemas/entities/de
 </td>
 <td>
 
-If `false`, indicates to the router that this subgraph doesn't define a [reference resolver](/graphos/get-started/guides/federate-schemas#2-define-a-reference-resolver) for this entity. This means that router query plans can't "jump to" this subgraph to resolve fields that aren't defined in another subgraph.
+If `false`, indicates to the router that this subgraph doesn't define a [reference resolver](/graphos/schema-design/federated-schemas/entities/intro/#2-define-a-reference-resolver) for this entity. This means that router query plans can't "jump to" this subgraph to resolve fields that aren't defined in another subgraph.
 
 Most commonly, you set this to `false` when [referencing an entity without contributing fields](/graphos/schema-design/federated-schemas/entities/contribute-fields#referencing-an-entity-without-contributing-fields).
 

docs/source/federation-2/new-in-federation-2.mdx

@@ -187,7 +187,7 @@ For more information, see [Resolving another subgraph's field](/graphos/schema-d
 
 ### Changes to `@key`
 
-Federation 2 adds a new optional argument to the `@key` directive: `resolvable`. You can set this argument to `false` to indicate that a particular subgraph doesn't define a [reference resolver](/graphos/get-started/guides/federate-schemas#2-define-a-reference-resolver) for that entity.
+Federation 2 adds a new optional argument to the `@key` directive: `resolvable`. You can set this argument to `false` to indicate that a particular subgraph doesn't define a [reference resolver](/graphos/schema-design/federated-schemas/entities/intro/#2-define-a-reference-resolver) for that entity.
 
 For example:
 

docs/source/query-plans.mdx

@@ -419,7 +419,7 @@ Flatten(path: "hotels.@") {
 
 Instead of containing a GraphQL operation, this `Fetch` node contains two GraphQL fragments, separated by `=>`.
 
-- The first fragment is a representation of the entity being resolved (in this case, `Hotel`). [Learn more about entity representations](/graphos/get-started/guides/federate-schemas/#2-define-a-reference-resolver).
+- The first fragment is a representation of the entity being resolved (in this case, `Hotel`). [Learn more about entity representations](/graphos/schema-design/federated-schemas/entities/intro/#2-define-a-reference-resolver).
 - The second fragment contains the entity fields and subfields that the router needs the subgraph to resolve (in this case, `Hotel.reviews` and `Review.rating`).
 
 When the router sees this special `Fetch` syntax, it knows to query a subgraph's [`Query._entities` field](/graphos/reference/federation/subgraph-specific-fields/#query_entities). This field is what enables a subgraph to provide direct access to any available fields of an entity.