fix: convert absolute /docs links to relative .mdx repo-wide (#2549)

Sweeps the remaining absolute /docs/... links (7 occurrences across 5
files) to relative ../path/file.mdx links per the repo convention.
Relative links with the file extension are validated at build time by
onBrokenMarkdownLinks; absolute route links are not.

Tier 1 Orgs page is handled separately in #2546. CONTRIBUTING.md is
left untouched: it is excluded from the docs build and its /docs link
is an intentional illustrative example.

Part of #2547

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: ElliotFriend

docs/tools/lab/transaction-dashboard.mdx

@@ -20,7 +20,7 @@ The dashboard automatically detects whether you're viewing a classic transaction
 
 This feature uses an RPC and RPC retains at maximum 7 days of historical data. Any transaction older than 7 days will be displayed as invalid.
 
-See [Indexers](/docs/data/indexers) and [Block Explorers](/docs/tools/developer-tools/block-explorers#stellarexpert) for reference
+See [Indexers](../../data/indexers/README.mdx) and [Block Explorers](../developer-tools/block-explorers.mdx#stellarexpert) for reference
 
 :::
 

docs/validators/README.mdx

@@ -18,7 +18,7 @@ If you are interested in running a validator node — because you issue an asset
 
 :::tip[Interested in Tier 1?]
 
-If your organization is evaluating or planning to join the Tier 1 quorum — the core group of organizations whose validators bear the safety and liveness of the network — see [Tier 1 Organizations](/docs/validators/tier-1-orgs) for requirements, estimated costs, and a step-by-step onboarding path. The Admin Guide below covers the technical setup for a single validator; the Tier 1 page covers what it takes to run three and join the quorum.
+If your organization is evaluating or planning to join the Tier 1 quorum — the core group of organizations whose validators bear the safety and liveness of the network — see [Tier 1 Organizations](./tier-1-orgs.mdx) for requirements, estimated costs, and a step-by-step onboarding path. The Admin Guide below covers the technical setup for a single validator; the Tier 1 page covers what it takes to run three and join the quorum.
 
 :::
 

docs/validators/admin-guide/configuring.mdx

@@ -96,7 +96,7 @@ QUALITY="MEDIUM"
 
 :::note[Tier 1 quality rating]
 
-The example above uses `QUALITY="MEDIUM"`, which is appropriate for a new validator building a track record. If your organization is a [Tier 1 participant](/docs/validators/tier-1-orgs) (or aspiring to become one), you should declare your own organization as `QUALITY="HIGH"`. Note that `HIGH` quality requires [publishing a history archive](/docs/validators/admin-guide/publishing-history-archives) — the requirement is programmatically enforced. Declaring a lower quality level significantly reduces your weight in [leader election](#impact-of-validator-quality-on-nomination) and may limit your participation in consensus.
+The example above uses `QUALITY="MEDIUM"`, which is appropriate for a new validator building a track record. If your organization is a [Tier 1 participant](../tier-1-orgs.mdx) (or aspiring to become one), you should declare your own organization as `QUALITY="HIGH"`. Note that `HIGH` quality requires [publishing a history archive](./publishing-history-archives.mdx) — the requirement is programmatically enforced. Declaring a lower quality level significantly reduces your weight in [leader election](#impact-of-validator-quality-on-nomination) and may limit your participation in consensus.
 
 :::
 

docs/validators/admin-guide/prerequisites.mdx

@@ -15,7 +15,7 @@ CPU, RAM, Disk and network depends on network activity. If you decide to colloca
 
 :::tip[For Tier 1 organizations]
 
-[Tier 1 organizations](/docs/validators/tier-1-orgs) run three geographically dispersed Full Validators, each meeting these requirements independently. Each node needs its own hardware, its own unique validator key, and its own history archive. Plan for three times the resources listed below, spread across different data centers or cloud regions. See [Tier 1 Organizations](/docs/validators/tier-1-orgs) for the full requirements and onboarding path.
+[Tier 1 organizations](../tier-1-orgs.mdx) run three geographically dispersed Full Validators, each meeting these requirements independently. Each node needs its own hardware, its own unique validator key, and its own history archive. Plan for three times the resources listed below, spread across different data centers or cloud regions. See [Tier 1 Organizations](../tier-1-orgs.mdx) for the full requirements and onboarding path.
 
 :::
 
@@ -90,9 +90,9 @@ A common misconception is that validators need to provision storage proportional
 
 **Soroban (smart contract) state is bounded by [state archival](https://developers.stellar.org/docs/learn/encyclopedia/storage/state-archival).** Contract data and contract code entries carry a rent balance; when a Temporary entry's balance reaches zero, it is deleted from live state. Temporary entries are cheaper to create than Persistent entries and dominate total contract data volume, so as they expire and are removed, a significant amount of state is freed up — keeping the live state on disk from growing unboundedly.
 
-**Classic ledger entries — accounts, trustlines, offers, claimable balances, liquidity pool shares, and data entries — do not expire.** They persist on the live state indefinitely. They grow slowly, though, because [reserve requirements](/docs/learn/fundamentals/stellar-data-structures/accounts#base-reserves-and-subentries) act as anti-spam friction on creation. In practice, the resulting working set still lands in the 30–60 GB range cited above, so local validator state stays compact even as cumulative network history grows.
+**Classic ledger entries — accounts, trustlines, offers, claimable balances, liquidity pool shares, and data entries — do not expire.** They persist on the live state indefinitely. They grow slowly, though, because [reserve requirements](../../learn/fundamentals/stellar-data-structures/accounts.mdx#base-reserves-and-subentries) act as anti-spam friction on creation. In practice, the resulting working set still lands in the 30–60 GB range cited above, so local validator state stays compact even as cumulative network history grows.
 
-**History archives live on object storage, not on the validator.** Full validators publish history archives to a separate object store (S3, R2, Backblaze B2, etc.) — that's where the multi-TB archive data lives. The validator process itself doesn't hold the archive on its local disk. See [Publishing History Archives](/docs/validators/admin-guide/publishing-history-archives) for the recommended setup.
+**History archives live on object storage, not on the validator.** Full validators publish history archives to a separate object store (S3, R2, Backblaze B2, etc.) — that's where the multi-TB archive data lives. The validator process itself doesn't hold the archive on its local disk. See [Publishing History Archives](./publishing-history-archives.mdx) for the recommended setup.
 
 **`CATCHUP_COMPLETE=true` is almost never the right choice.** This setting makes the node sync the entire ledger from genesis on startup and is rarely appropriate for a validator. The standard pattern for new validators — including new Tier 1 candidates — is to sync against current network state, publish a history archive forward from that point, and use `stellar-archivist mirror` to backfill historical data into the published archive as a separate operation. The validator's local disk requirements are determined by the live state model above, not by historical depth.
 

docs/validators/admin-guide/publishing-history-archives.mdx

@@ -7,7 +7,7 @@ If you want to run a [Full Validator](../README.mdx#full-validator), you need to
 
 :::caution[One archive per node]
 
-Each node must publish to its own dedicated archive. Writing to the same archive from multiple nodes is not supported and will result in undefined behavior, potentially including data loss. If you're running multiple Full Validators (as [Tier 1 organizations](/docs/validators/tier-1-orgs) do), configure a separate archive for each — for example, `history-a.example.com`, `history-b.example.com`, and `history-c.example.com`.
+Each node must publish to its own dedicated archive. Writing to the same archive from multiple nodes is not supported and will result in undefined behavior, potentially including data loss. If you're running multiple Full Validators (as [Tier 1 organizations](../tier-1-orgs.mdx) do), configure a separate archive for each — for example, `history-a.example.com`, `history-b.example.com`, and `history-c.example.com`.
 
 :::