Use a common prefix for internal endpoints

[fafk]

Description

We now have a few endpoints that we don't want to expose to the public and every single one of them has a) a rule in WAF b) a rule on the infra level that exposes it to partners with an API key.

Instead of setting these every time we create a new internal endpoint we can use the same rules for all endpoints with the /api/internal prefix.

How to test

Existing e2e tests.

[github-actions]

Reminder: Please consider backward compatibility when modifying the API specification.
If breaking changes are unavoidable, ensure:

• You explicitly pointed out breaking changes.
• You communicate the changes to affected teams (at least Frontend team and SAFE team).
• You provide proper versioning and migration mechanisms.

---

Caused by:

• crates/orderbook/openapi.yml

[gemini-code-assist]

Code Review

This pull request updates the debug and simulation API endpoints by prefixing them with /internal/, changing the path from /api/v1/debug/ to /api/internal/v1/debug/. These changes are consistently applied across the documentation, E2E tests, OpenAPI specification, and the API route handler. No critical issues found; I have no feedback to provide.

[squadgazzz]

If a reverse proxy or load balancer has a rule "forward all /api/* to the backend", then /api/internal/* gets forwarded too, so internal endpoints are exposed unless there's an explicit deny rule higher up. With /internal/api/*, a blanket /api/* forward rule can't accidentally reach internal endpoints. Internal routes are in a completely separate namespace by default.

[AryanGodara]

Minor note: the Prometheus metric labels emitted by the with_matched_path_metric (in api.rs1 but in L115, not in this diff) middleware will change (e.g. GET /api/v1/debug/order/{uid} → GET /api/internal/v1/debug/order/{uid}), so any Grafana panels filtering on the old labels will need updating.
I"m not sure if we have a dashboard which depends on this, or if the endpoints in that are hardcoded. But maybe worth a check.

[MartinquaXD]

Putting restricted / permissioned endpoints under a common prefix makes sense to me.
internal feels like a poor name, though. I think restricted would be more fitting.