fix(xray): keep XDRIVE storage and Vision flow within what xray-core runs

xray-core opens an XDRIVE stream's storage only when the inbound starts
listening, so a Google Drive inbound saved with the form's defaults (no
folder, no secrets), a local one without a folder, or a template one
whose template xray cannot use stopped xray and every other inbound with
it. validateXDriveStorage applies the core's storage rules at save, on
inbound add/update and on the xray template's inbounds and outbounds:
the service must be local, Google Drive or template; local and Google
Drive need a remoteFolder; Google Drive needs its three non-empty
secrets; a template must pass newTemplateStorage's checks (put, get,
list and delete urls, and a list namesRegex with one capture group).

A VLESS client kept its xtls-rprx-vision flow when its inbound moved to
a transport that cannot carry it, and GetXrayConfig only honoured
DisableFlow, so the server demanded Vision there and refused every
client. GetXrayConfig and the outbound form now apply the Vision gate,
and that gate now follows the core in the backend, the subscription
service and the frontend: TLS/REALITY on raw TCP, or VLESS encryption on
any transport (xray runs Vision inside encryption.CommonConn whatever
the transport, not only on XHTTP). The outbound modal passes the VLESS
encryption into the gate and gates Mux on the effective flow.

docs/content/docs/en/config/transports.mdx

@@ -204,7 +204,7 @@ The `xtls-rprx-vision` flow is fast and DPI-resistant. It's available for
 
 - the transport is raw **TCP** with **TLS** or **REALITY** security (classic
   XTLS-Vision), or
-- the transport is **XHTTP** with VLESS encryption enabled (see below).
+- VLESS encryption is enabled, on any transport (see below).
 
 Set the flow on the VLESS **client**, not the inbound. With classic Vision on
 TCP, the panel can also offer a **Vision seed** once a client uses the flow.
@@ -213,7 +213,7 @@ TCP, the panel can also offer a **Vision seed** once a client uses the flow.
 
 VLESS supports post-quantum **encryption** (ML-KEM / `mlkem768x25519`), stored in
 the inbound's `decryption` (server) and clients' `encryption` (for link
-generation). When enabled, it unlocks the Vision flow over XHTTP. Generate the
+generation). When enabled, it unlocks the Vision flow on any transport. Generate the
 keys from the panel's VLESS settings.
 
 ## Shadowsocks ciphers