perf(clients): apply a multi-inbound client create concurrently

Creating or attaching a client across N inbounds called AddInboundClient
once per inbound, strictly one after another. When those inbounds live on
different nodes each call is a full node round-trip bounded by the 10s
remote timeout, so the request cost the SUM of every node's latency: two
nodes felt instant, three took ~13s and timed out bot callers, which is
how it surfaced as "two out of four account creations fail".

Split the per-inbound preparation from the apply. Preparation stays
ordered and single-threaded because fillProtocolDefaults mints the shared
credentials on the first inbound and every later one reuses them; the
applies then run concurrently, capped at inboundFanoutConcurrency. A
4-node create measured 1.205s -> 0.307s with peak overlap 1 -> 4.

Consequences of no longer aborting at the first failing inbound:

- Every apply error is tagged with its inbound and the failures are
  joined, so all of them reach the caller instead of just the first.
- The fanout goroutines recover their own panics. Off the request
  goroutine gin's Recovery no longer covers them, and an unrecovered
  panic would kill the panel rather than fail one inbound.
- A partly-applied call commits clients on the inbounds that succeeded,
  so the controller and the LDAP job now read needRestart before the
  error check; otherwise Xray was never flagged for the work that landed.
- limitHwid is applied only when every inbound succeeded. Applying it
  after a failure rewrites limit_hwid and trims the registered devices of
  an email that already existed, which is silent data loss on an
  operation the panel reported as failed.

Update the API docs for the new partial-application contract and the
inbound-tagged error strings.

docs/content/docs/en/reference/api/clients.mdx

@@ -550,21 +550,34 @@ _openapi:
 
 
           WireGuard is the only one of these that can fail. Allocation widens
-          the search to the containing /16 before giving up with `wireguard: no
-          free address available in <scope>`, and an `allowedIPs` supplied by
-          the caller is validated instead of allocated: `wireguard: allowedIPs
-          entry already used by another client: <address>` when a different
-          client of that same inbound already holds it. The check is per
-          inbound, so the same address on two different inbounds is accepted.
-          The same validation runs on POST /panel/api/clients/{email}/attach,
-          where a client that already carries an address brings it along.
+          the search to the containing /16 before giving up with `inbound <id>:
+          wireguard: no free address available in <scope>`, and an `allowedIPs`
+          supplied by the caller is validated instead of allocated: `inbound
+          <id>: wireguard: allowedIPs entry already used by another client:
+          <address>` when a different client of that same inbound already holds
+          it. The check is per inbound, so the same address on two different
+          inbounds is accepted. The same validation runs on POST
+          /panel/api/clients/{email}/attach, where a client that already carries
+          an address brings it along.
+
+
+          An `inboundIds` entry that names no existing inbound rejects the whole
+          call before anything is written. Past that, the inbounds are applied
+          concurrently and independently: one that fails no longer stops the
+          others, so a `success:false` response can still have created the
+          client on the rest. Every error names the inbound it came from
+          (`inbound 7: <message>`), and several failures are reported together,
+          one per line. `limitHwid` is applied only when every inbound
+          succeeded, so re-run the call after fixing the failure.
         heading: create-a-new-client-and-attach-it-to-one-or-more-inbounds-in-a-single-call-body-is-json-per-protocol-secrets-are-generated-server-side-when-omitted-so-callers-can-send-only-the-universal-fields
       - content: 'A WireGuard client brings its stored `allowedIPs` into the new inbound
           instead of being given a fresh address, so the call fails with
-          `wireguard: allowedIPs entry already used by another client:
-          <address>` when a different client of the target inbound already holds
-          it. Free the address on that inbound first — see POST
-          /panel/api/clients/add for the full rule.'
+          `inbound <id>: wireguard: allowedIPs entry already used by another
+          client: <address>` when a different client of the target inbound
+          already holds it. Free the address on that inbound first — see POST
+          /panel/api/clients/add for the full rule. Inbounds are applied
+          independently, so the remaining ones are still attached and a
+          `success:false` response can be partial.'
         heading: attach-an-existing-client-to-one-or-more-additional-inbounds-body-is-json
 ---