docs: fix broken links to renamed repository paths (#12618)

# Which Problems Are Solved

Several links in the docs point at repository paths that no longer
exist, so they 404 on GitHub:

- The `load-test` directory was renamed to `benchmark`. The benchmarks
page still links to `load-test`, `load-test/Makefile` and
`load-test/README.md` (5 occurrences).
- `apps/docs/content/index.mdx` links to `CONTRIBUTING.mdx`, but the
file is `CONTRIBUTING.md`.
- The login-app guide links to `apps/login/src/middleware.ts`, which was
renamed to `apps/login/src/proxy.ts` in the Next.js 16 upgrade (#11629).

# How the Problems Are Solved

- Point the benchmarks page at `benchmark/`, `benchmark/Makefile` and
`benchmark/README.md`. The `#test` anchor still resolves —
`benchmark/README.md` has a `### Test` heading.
- Fix the `CONTRIBUTING.md` extension.
- Point the middleware example at `apps/login/src/proxy.ts`.

Verified by extracting every
`github.com/zitadel/zitadel/{blob,tree}/main/...` link from
`apps/docs/content` and resolving each one against the working tree —
all 14 distinct paths now exist.

# Additional Changes

- Prose in the benchmarks page that names the directory ("the load-test
Makefile", "the load-test readme") now says "benchmark". Generic uses of
"load-test"/"load-testing" as an activity are left as they are.

# Additional Context

- The versioned docs under `apps/docs/content/v4.13`–`v4.16` contain the
same stale links, but those directories are generated at build time from
release tags by `apps/docs/scripts/fetch-remote-content.mjs` and are
gitignored, so they cannot be fixed from `main`. The published pages for
those versions will keep the old links.
- `apps/docs/scripts/check-links.ts` skips anything starting with
`http`, which is why these went unnoticed. Teaching it to resolve
`github.com/zitadel/zitadel/blob/main/<path>` links against the working
tree would catch this class of breakage in CI — not done here to keep
the PR focused.

Co-authored-by: Claude Opus 5 <[email protected]>

apps/docs/content/apis/benchmarks/index.mdx

@@ -22,7 +22,7 @@ The primary goal is to assess if ZITADEL can scale to required proportion. The g
 
 ## Procedure
 
-First we determine the “target” of our load-test. The target is expressed as a make recipe in the load-test [Makefile](https://github.com/zitadel/zitadel/blob/main/load-test/Makefile). See also the load-test [readme](https://github.com/zitadel/zitadel/blob/main/load-test/README.md) on how to configure and run load-tests.
+First we determine the “target” of our load-test. The target is expressed as a make recipe in the benchmark [Makefile](https://github.com/zitadel/zitadel/blob/main/benchmark/Makefile). See also the benchmark [readme](https://github.com/zitadel/zitadel/blob/main/benchmark/README.md) on how to configure and run load-tests.
 A target should be tested for longer periods of time, as it might take time for certain metrics to show up. For example, cloud SQL samples query insights. A runtime of at least **30 minutes** is advised at the moment.
 
 After each iteration of load-test, we should consult the [After test procedure](#after-test-procedure) to conclude an outcome:
@@ -35,7 +35,7 @@ After each iteration of load-test, we should consult the [After test procedure](
 
 ### Benchmark definition
 
-Tests are implemented in the ecosystem of [k6](https://k6.io). The tests are publicly available in the [zitadel repository](https://github.com/zitadel/zitadel/tree/main/load-test). Custom extensions of k6 are implemented in the [xk6-modules repository](https://github.com/zitadel/xk6-modules).
+Tests are implemented in the ecosystem of [k6](https://k6.io). The tests are publicly available in the [zitadel repository](https://github.com/zitadel/zitadel/tree/main/benchmark). Custom extensions of k6 are implemented in the [xk6-modules repository](https://github.com/zitadel/xk6-modules).
 The tests must at least measure the request duration for each API call. This gives an indication on how zitadel behaves over the duration of the load test.
 
 ### Metrics
@@ -73,7 +73,7 @@ The following metrics must be collected for each test iteration. The metrics are
 
 #### Make recipes
 
-Details about the tests implemented can be found in [this readme](https://github.com/zitadel/zitadel/blob/main/load-test/README.md#test).
+Details about the tests implemented can be found in [this readme](https://github.com/zitadel/zitadel/blob/main/benchmark/README.md#test).
 
 ### Test conclusion
 

apps/docs/content/guides/integrate/login-ui/login-app.mdx

@@ -130,7 +130,7 @@ When setting up the new Login app for OIDC, ensure it meets the following requir
 - The OIDC Proxy sets `x-zitadel-public-host` which is the host, your Login app is deployed to `ex. login.example.com`.
 - The OIDC Proxy sets `x-zitadel-instance-host` which is the host of your instance `ex. test-hdujwl.zitadel.cloud`.
 
-You can review an example implementation of a middleware [here](https://github.com/zitadel/zitadel/blob/main/apps/login/src/middleware.ts).
+You can review an example implementation of a middleware [here](https://github.com/zitadel/zitadel/blob/main/apps/login/src/proxy.ts).
 
 #### Deploy to Vercel
 

apps/docs/content/index.mdx

@@ -126,7 +126,7 @@ Join the community and get help.
   />
   <Card
     title="Contribute"
-    href="https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.mdx"
+    href="https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md"
     icon={<Heart />}
     description="Help us improve ZITADEL and its documentation."
   />