docs: add TUIC v5 to READMEs, guides, and protocol references (#6511)

* docs: add TUIC v5 to READMEs, guides, and protocol references

* docs: address review feedback on TUIC architecture, external links, and i18n parity

* docs(tuic): drop the Xray-routing claim and qualify Limit IP for TUIC

The README feature bullet in all seven locales credited the TUIC sidecar
with "seamless Xray routing". A TUIC inbound never enters the Xray config
(internal/web/service/xray.go skips model.TUIC) and the generated
tuic-server config carries no forwarding target, so decrypted TUIC
traffic egresses from the sidecar directly and Xray routing rules never
see it; docs/architecture.md in this same branch already says so. An
operator reading the bullet would expect geo blocking and outbound
selection to cover TUIC clients.

The client field table marks Total (GB) as inbound-level for TUIC but
left Limit IP at "all". The IP-limit job's only data source is Xray's
online-stats API (internal/web/job/check_client_ip_job.go), which TUIC
clients never reach, so a Limit IP set on a TUIC client is silently
unenforced. Qualify that row the same way in en, fa, ru and zh.

---------

Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>

docs/architecture.md

@@ -19,13 +19,19 @@ Xray JSON config from that state, supervises the Xray child process, and exposes
 WebSocket API. A React SPA (built by Vite, embedded into the Go binary) is the UI. A second,
 separate HTTP server serves **subscription links** to end users.
 
-The panel supervises **two managed child processes**: Xray-core itself and — when MTProto
-inbounds exist — the `mtg-multi` Telegram-proxy binary (`github.com/mhsanaei/mtg-multi`, a
-multi-secret fork built from source; `internal/mtproto/`). One process per inbound serves
-every attached client's FakeTLS secret through the fork's `[secrets]` section, plus optional
-per-client sponsored-channel ad-tags via `[secret-ad-tags]`. A client or ad-tag edit is
-hot-applied via the fork's management API (`PUT /secrets`, guarded by a per-process bearer
-token), with a process restart as the fallback on older binaries.
+The panel supervises **managed child processes**: Xray-core itself and — when MTProto or
+TUIC inbounds exist — dedicated child proxy binaries:
+
+- **`mtg-multi` for MTProto inbounds** (`github.com/mhsanaei/mtg-multi`, a multi-secret fork
+  built from source; `internal/mtproto/`): One process per inbound serves every attached
+  client's FakeTLS secret through the fork's `[secrets]` section, plus optional per-client
+  sponsored-channel ad-tags via `[secret-ad-tags]`. A client or ad-tag edit is hot-applied via
+  the fork's management API (`PUT /secrets`, guarded by a per-process bearer token), with a
+  process restart as the fallback on older binaries.
+- **`tuic-server` for TUIC v5 inbounds** (`internal/tuic/`): One process per inbound runs on
+  loopback behind an in-process native Go UDP relay that owns the public port and meters
+  traffic deltas. The sidecar handles decrypted client traffic standalone, independent of
+  Xray routing and outbounds.
 
 Servers and processes, all launched from `main.go`:
 
@@ -35,6 +41,7 @@ Servers and processes, all launched from `main.go`:
 | **Subscription** | `internal/sub`                    | Public endpoint that hands out client configs (raw / JSON / Clash) | `subPort` setting |
 | **Xray-core**    | supervised via `internal/xray`    | The actual proxy engine; a child process, not Go code              | `inbounds[].port` |
 | **mtg-multi**    | supervised via `internal/mtproto` | MTProto proxy child process for MTProto inbounds (multi-secret)    | per inbound       |
+| **tuic-server**  | supervised via `internal/tuic`    | TUIC v5 proxy child process fronted by a Go UDP relay              | per inbound       |
 
 Two key ideas that explain most of the complexity: