docs: split-mode setup guide, architecture diagrams, cert script, build

README:
- New 'Split-mode setup' section: motivation, firewall rules, step-by-step
  instructions for both VPN tunnel and TLS distribution options
- Split-mode bullet added to Features list
- Notes on DPI-resistant tunnels (Shadowsocks, VLESS/XRay, Hysteria2) for
  Russian deployment; standard VPN protocols (WireGuard, OpenVPN) may be blocked
- Install instructions updated to use `make init-config` (copies templates,
  auto-detects public IP) instead of manual cp; ROLE= documented throughout
- Split-mode Step 4 uses `make ROLE=back/front` so template-change detection
  works correctly after `git pull`

Makefile:
- ROLE ?= both variable selects config templates (both/front/back)
- Config prereq rules use $(SYS_CONFIG_SRC) / $(VM_ARGS_SRC) based on ROLE
- New `init-config` target: force-copies templates, auto-detects public IP,
  prints edit reminder; replaces manual cp in install workflow

scripts/gen_dist_certs.sh:
- Two-step workflow: `init <dir>` on back server (CA + back cert),
  `add-node <dir> <name>` per front server (cert signed by existing CA)
- Generates per-node ssl_dist.<name>.conf with paths substituted (no
  NODE_NAME placeholder to edit manually)
- ssl_dist.<name>.conf is now used directly (no rename to ssl_dist.conf);
  vm.args examples and README updated to match

config/vm.args.{front,back}.example:
- -ssl_dist_optfile points to role-specific filename (ssl_dist.front.conf /
  ssl_dist.back.conf) so cert files can be copied as-is without renaming

AGENTS.md:
- Role-overview Mermaid flowchart showing front/back/both process split
- Data-plane section replaced with links to doc/ (no duplication)
- Supervision tree, key interactions, split-mode config keys updated

doc/handler-downstream-flow.md, doc/migration-flow.md:
- Mermaid box grouping to visually separate FRONT and BACK node participants
- erpc:call reference corrected (was rpc:call)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

doc/handler-downstream-flow.md

@@ -9,19 +9,30 @@ and the steady-state data flow that follows.
 - `mtp_down_conn` — multiplexed TCP connection to a Telegram DC
 - `Telegram DC` — the upstream Telegram data-centre server
 
+In **split mode** (`node_role = front / back`) `mtp_handler` runs on the front
+node and `mtp_dc_pool` / `mtp_down_conn` run on the back node.  The pool is
+addressed as `{mtp_dc_pool_N, BackNode}` — Erlang distribution makes the
+`gen_server:call` and all subsequent casts transparent across nodes.  Multiple
+front nodes can share the same back node; the pools multiplex over all
+upstream connections regardless of origin.
+
 ```mermaid
 sequenceDiagram
     participant Client as Telegram client
-    participant Handler as mtp_handler
-    participant Pool as mtp_dc_pool
-    participant Down as mtp_down_conn
+    box LightBlue "FRONT node"
+        participant Handler as mtp_handler
+    end
+    box LightGreen "BACK node"
+        participant Pool as mtp_dc_pool
+        participant Down as mtp_down_conn
+    end
     participant TG as Telegram DC
 
     Client->>Handler: TCP connect + Hello bytes
 
     Note over Handler: decode protocol headers<br/>(fake-TLS / obfuscated / secure)<br/>stage: hello → tunnel
 
-    Note over Handler: resolve pool: whereis(dc_to_pool_name(DcId))<br/>(registered name lookup; falls back to default DC from mtp_config if not found)
+    Note over Handler: resolve pool:<br/>single-node: whereis(dc_to_pool_name(DcId))<br/>split mode:  erpc:call(BackNode, erlang, whereis, [PoolName])<br/>→ returns {PoolName, BackNode}<br/>(falls back to default DC from mtp_config if not found)
     Handler->>Pool: mtp_dc_pool:get(Pool, self(), Opts) [sync]
     Pool-->>Down: upstream_new(Handler, Opts) [cast]
     Pool->>Handler: Downstream pid

doc/migration-flow.md

@@ -11,13 +11,26 @@ surviving (or freshly-started) DC connection transparently.
 - `mtp_handler` — one process per connected Telegram client
 - `mtp_down_conn (new)` — replacement downstream spawned by the pool
 
+**Split-mode note:** in `front/back` split mode `mtp_handler` lives on the
+front node and `mtp_dc_pool` / `mtp_down_conn` live on the back node.  Every
+message in the diagram below that crosses the front↔back boundary (the
+`migrate` cast, `upstream_new` cast, `Pool->>Handler` reply, etc.) is carried
+transparently by Erlang distribution — no code changes are needed because
+Erlang PIDs and `gen_server` calls work across nodes unchanged.  Process
+monitors also fire on node disconnection, so a back-node restart causes all
+affected front-node handlers to exit cleanly.
+
 ```mermaid
 sequenceDiagram
     participant TG as Telegram
-    participant OldDown as mtp_down_conn (old)
-    participant Pool as mtp_dc_pool
-    participant Handler as mtp_handler
-    participant NewDown as mtp_down_conn (new)
+    box LightGreen "BACK node"
+        participant OldDown as mtp_down_conn (old)
+        participant Pool as mtp_dc_pool
+        participant NewDown as mtp_down_conn (new)
+    end
+    box LightBlue "FRONT node"
+        participant Handler as mtp_handler
+    end
 
     TG->>OldDown: TCP close