Two multi-inbound client bugs from issue #4834:
- Clearing a client's reverse tag never persisted: SyncInbound keeps a non-empty sticky guard on reverse (shared with node-sync/rename), so the cleared value never reached the canonical clients.reverse column the edit form reads. Update now writes that column authoritatively from the submitted client, matching how it already writes email/updated_at directly.
- Attaching a new inbound reset xtls-rprx-vision: Attach seeded its wire client from the canonical clients.flow column, which a non-flow inbound can zero during the preceding update. It now derives the flow from EffectiveFlow (the per-inbound flow_override), so flow-capable targets keep the flow and others stay empty.
Adds service tests for both paths and a guard test confirming node-snapshot sync still preserves a stored reverse tag.
SyncInbound runs once per inbound and unconditionally overwrites the canonical clients.Flow column. A non-flow inbound (Hysteria, WS, gRPC) strips flow to "", so when it syncs after a VLESS Reality inbound the column is wiped, and the hydrate endpoint returned that empty value — the edit form loaded a blank flow for multi-inbound clients (#4792).
Derive the hydrate flow from the first flow-capable client_inbounds.flow_override instead, which is always correct and order-independent. A non-empty guard in SyncInbound was rejected because it would make flow impossible to clear.
Closes#4792
A client shared across inbounds (e.g. VLESS+TCP+Reality and VLESS+WS+TLS)
had its `flow` applied globally, so enabling xtls-rprx-vision for Reality
broke the WS+TLS inbound for the same client (#4628).
Gate flow per inbound at every fan-out site via clientWithInboundFlow,
reusing inboundCanEnableTlsFlow (VLESS+TCP+TLS/Reality only), and make
ListForInbound treat flow_override as authoritative so an empty override
means "no flow on this inbound" instead of inheriting the record's global
flow. Also tighten buildTargetClientFromSource (copy-clients) to gate on
transport, not just protocol.
