feat: 合并边缘节点运维并完善 Surge 配置安全

迁入通用节点部署工具、离线交付页生成器和共用技能，隔离真实配置与交付产物。统一 Codex 与 Claude Code 开发约定，补充节点迁移与运维文档。

完善 FINAL、策略组引用、输入校验、Surge 字段编码与 AI DNS 例外保护，增加隔离测试和订阅验证工具。

验证：全量类型检查、44 项单测、前端构建、脚本语法、技能入口与凭据隔离检查均通过。

.claude/skills/edge-node-multi-protocol/references/protocol-choice.md

@@ -0,0 +1,61 @@
+# Why VMess + Trojan + Shadowsocks, and when to add a fourth
+
+This skill's default 6-inbound target (3 protocols × direct/WARP) was chosen for a specific
+combination of constraints: client compatibility (Surge excludes the Shadowsocks-over-WS lines; see the project capability matrix), transport safety (no UDP, so nothing here is exposed to networks that
+throttle UDP indiscriminately), and zero extra server software (all three are native to
+3x-ui/Xray-core — no sing-box, no separate Hysteria2/TUIC binary to maintain).
+
+If your constraints are different, the right protocol set is different too. This file is the
+reasoning, not a rule — read it before assuming the default 3 are the "right" choice for a new
+node.
+
+## The three defaults
+
+| Protocol | Transport overhead | GFW-detection posture | Client support |
+|---|---|---|---|
+| VMess (+WS+TLS) | Two encryption layers (VMess's own AEAD, on top of the outer TLS) + WS framing — heaviest of the three | Weakest of the three; historically a specific target of active probing, and Xray-core itself now prints a deprecation warning for it | Nearly universal |
+| Trojan (+WS+TLS) | One layer (just the outer TLS) + WS framing — noticeably lighter than VMess | Stronger: Trojan's whole design is "indistinguishable from a real HTTPS site to anyone without the password" | Nearly universal, including Surge |
+| Shadowsocks (+WS+TLS) | Similar to Trojan — SS's own cipher is lightweight, WS+TLS is the same cover as the others | Comparable to VMess's cover level, but without VMess's specific deprecated-protocol baggage | Supported by compatible WS clients; Surge does not support SS over WS |
+
+All three are plain TCP end-to-end between client and server (the WS layer rides on TCP), so
+none of them are exposed to networks that indiscriminately throttle UDP — that includes the
+"UDP forwarding" toggle some clients show for VMess/Trojan/SS: it tunnels UDP *payloads* inside
+the already-established TCP connection, it doesn't open a real UDP socket to the server.
+
+## What "UDP is faster" actually means (and doesn't)
+
+QUIC-based protocols (Hysteria2, TUIC) run on top of UDP, and that fact alone doesn't make them
+faster — raw UDP has no reliability or congestion control built in. Their speed advantage comes
+from what they build *on top of* UDP: no head-of-line blocking across multiplexed streams,
+faster connection setup/resumption, connection migration across network changes, and (for
+Hysteria2 specifically) an aggressive custom congestion-control algorithm designed for lossy
+links. That advantage is real and large specifically on **high-latency or high-packet-loss**
+networks. On a clean, low-latency network, well-implemented TCP+TLS (Trojan, VLESS) is often
+just as fast, sometimes faster (QUIC's per-packet encryption has real per-byte CPU cost that
+kernel-optimized TCP+TLS doesn't). Don't add a UDP-based protocol to this skill's target list on
+the assumption that "UDP is just faster" — add it because you specifically need resilience on
+bad networks or fast network-switching, and you've weighed that against UDP's other real risk:
+plenty of networks throttle/block UDP indiscriminately, which no amount of protocol-level
+cleverness fixes.
+
+## When to add a fourth protocol
+
+- **Client doesn't support any of the three (rare)** — e.g. something that only speaks VLESS or
+  Hysteria2. Add exactly what that client needs; see `3x-ui-schema.md` for the
+  mechanical steps (VLESS/VLESS+REALITY are native to 3x-ui/Xray-core, no extra software).
+- **You specifically need the strongest current anti-active-probing posture** — VLESS+REALITY
+  (or Trojan+REALITY; Xray-core supports REALITY on both) borrows a real site's TLS handshake,
+  which is currently the hardest thing for active probing to distinguish from genuinely visiting
+  that site. Native to 3x-ui. Needs picking a "borrowed" target site with real TLS 1.3, decent
+  traffic, and no active blocking of its own in your target region.
+- **You specifically need next-generation traffic-pattern resistance** — AnyTLS defends against
+  statistical traffic-shape analysis (packet size/timing), which REALITY's handshake-mimicry
+  doesn't address by itself. Not native to 3x-ui/Xray-core — needs sing-box installed
+  server-side, as a separate service alongside 3x-ui (different ports, no conflict).
+- **You specifically need resilience on bad/mobile networks and already have a UDP fallback
+  elsewhere** — Hysteria2 (preferred over TUIC: larger community, more obfuscation options,
+  more battle-tested) if you don't already have a node covering this case. Also needs sing-box
+  or a standalone Hysteria2 binary, not native to 3x-ui.
+- **Don't add a protocol "just in case."** Every inbound is one more thing to keep working
+  through aaPanel/3x-ui/Xray version upgrades — see `pitfalls.md` for how much
+  version drift alone (not malicious blocking) can break a working inbound.