removed toio console because of heavy ram usage

docs/src/build-and-deploy.md

@@ -41,7 +41,6 @@ environment across different machines.
 * `make test`: Runs all workspace tests using the Stable toolchain.
 * `make lint`: Runs clippy to find common mistakes and improve code quality.
 * `make lint-fix`: Automatically applies clippy suggestions (where possible).
-* `make build-diagnostic`: Builds the backend with `tokio-console` support (diagnostic only, not part of normal releases).
 * `make markdown-lint`: Checks all .md files for formatting consistency.
 
 **Formatting**:
@@ -129,22 +128,6 @@ rustup target add x86_64-unknown-linux-musl
 cargo build -p tuliprox --target x86_64-unknown-linux-musl --release
 ```
 
-### Diagnostic Build (tokio-console)
-
-To diagnose async hangs (tasks that never complete, locks held across `.await`), build the diagnostic binary:
-
-```bash
-make build-diagnostic
-TULIPROX_TOKIO_CONSOLE=1 ./target/release/tuliprox -s -p ./config
-tokio-console            # defaults to http://127.0.0.1:6669
-```
-
-This build compiles `tokio` with `--cfg tokio_unstable` and enables the optional `console-subscriber`. It is a separate
-binary and normal release builds are unaffected. The experimental Docker image
-(`ghcr.io/euzu/tuliprox:experimental`) is built this way and enables the subscriber by default. See
-[Runtime Liveness Watchdog](./operations-debugging.md#8-runtime-liveness-watchdog) for the always-available (opt-in)
-watchdog that does not require a special build.
-
 ### Cross-Compilation (ARM / Windows)
 
 To compile for architectures other than your host, use the `cross` tool or native mingw packages.

docs/src/operations-debugging.md

@@ -502,30 +502,3 @@ While the watchdog runs, `GET /healthcheck` gains a `runtime` object:
 `runtime.status` is `stalled` once the heartbeat stops. The top-level `status` intentionally stays `ok` for as long as the
 HTTP server answers, so no orchestrator restarts the process. If the whole runtime is wedged, the endpoint cannot answer
 at all — in that case the watchdog log is the signal.
-
----
-
-## 9. tokio-console Diagnostic Build
-
-`tokio-console` shows live which tasks exist, where each one is waiting, and which lock it holds. It is the tool to
-identify an async deadlock. It needs a special build and is never part of the standard production image.
-
-```bash
-# Build the diagnostic binary (requires RUSTFLAGS="--cfg tokio_unstable" internally)
-make build-diagnostic
-
-# Run it with the subscriber enabled and attach the console
-TULIPROX_TOKIO_CONSOLE=1 ./target/release/tuliprox -s -p ./config
-tokio-console            # defaults to http://127.0.0.1:6669
-```
-
-The experimental Docker image (`ghcr.io/euzu/tuliprox:experimental`) already carries this build and enables it by default.
-
-Notes:
-
-* The default release build compiles none of this: no `tokio_unstable`, no `console-subscriber`. There is no runtime cost
-  in normal images.
-* The console gRPC server has no authentication. Keep it on loopback (the default) or, if you must publish a port,
-  publish it only on the host loopback (`-p 127.0.0.1:6669:6669`).
-
----

docs/src/troubleshooting.md

@@ -235,9 +235,6 @@ the grace period (`TULIPROX_WATCHDOG_RESTART_GRACE_MS`, default 30 s), so a conf
 brings the container back automatically. Use mode `1` while you are still investigating a cause, and mode `2` once a
 restart is the acceptable recovery.
 
-**How to find the exact task and lock:** use the `tokio-console` diagnostic build (see
-[Runtime Liveness Watchdog](./operations-debugging.md#8-runtime-liveness-watchdog)) or run the experimental image.
-
 **Immediate mitigation:** restart the container. The watchdog log is what tells you the stall happened on its own and
 captures what every thread was doing at that moment.