feat(sub): make the host "Mihomo X25519" switch drop ML-KEM (#6803)

The per-host Mihomo X25519 switch has been stored since managed hosts landed,
but no renderer read it, while every REALITY proxy was forced to
support-x25519mlkem768: true. On some networks DPI drops the second segment of
an ML-KEM ClientHello and blackholes the server for that client. A host with the
switch on now gets support-x25519mlkem768: false and no ML-KEM hint in its vless
link; switches saved while they had no effect are cleared once, so upgrading
does not silently change existing subscriptions.

A REALITY host's fingerprint now reaches the Clash and JSON outputs, and every
host endpoint gets its own deep copy of the stream, so one host's blank SNI,
fingerprint, Host header or path no longer inherits another host's value.

docs/content/docs/en/config/reality.mdx

@@ -131,9 +131,11 @@ vless://<uuid>@<server>:443?security=reality&pbk=<public-key>&sid=<short-id>&sni
   with Mihomo's uTLS v1.8.7); enabling the flag cannot upgrade an old fingerprint.
   Raw `vless://` links carry the equivalent `support-x25519mlkem768=true` hint;
   clients that support this URI extension, including current Mihomo builds, apply
-  it on import. Very old REALITY servers that reject ML-KEM require a per-node
-  client override setting this option to `false`, or a server upgrade. Clearing
-  the version limit alone does not fix the handshake.
+  it on import. Servers on Xray-core older than 26.9.8 accept a plain `X25519`
+  hello, and very old ones reject ML-KEM outright. For those, or where a network
+  drops the larger ML-KEM ClientHello, enable **Mihomo X25519** on a Host: its
+  Clash proxy gets `support-x25519mlkem768: false` and its `vless://` link drops
+  the hint. Clearing the version limit alone does not fix the handshake.
 
 </Callout>