feat: allow unrestricted independent job concurrency

docs/system-design.md

@@ -133,10 +133,13 @@ a resource may be active or queued at a time. This prevents incompatible
 baselines even when jobs would use different nodes or observe different sides
 of a hybrid identity.
 
-Defaults allow one active data-moving job per client and one per route. A job
-must acquire its source client, target client, route, and resource reservation
-atomically. Disjoint node pairs may run concurrently. Route setup is a
-preflight activity and does not permit a data step to bypass these leases.
+By default every eligible queued job is claimed in the same scheduler pass and
+independent jobs run concurrently on each client; physical service and storage
+capacity are the limit. Set `enforce_concurrency_limits=true` on control to
+enable the optional one-per-client/one-per-route gates. A job always retains
+its resource reservation, and commands for the same job remain serialized.
+Route setup is a preflight activity and does not permit a data step to bypass
+the resource reservation.
 
 Offline nodes do not prevent unrelated jobs from being listed or run. A job
 requiring an offline node remains waiting indefinitely; it does not consume an
@@ -154,6 +157,12 @@ advances to the next step. On reconnect:
 4. Control observes relevant qBittorrent, Syncthing, staging, and manifest
    state before selecting retry, resume, compensation, cleanup, or manual
    intervention.
+
+If a connection disappears while a synchronous job operation is in progress,
+the client journals events locally, reconnects indefinitely, and serializes a
+replayed command behind the in-flight operation for that job. The replay reads
+the journal rather than repeating the data operation. This applies to every
+transfer step, including post-commit staging cleanup.
 5. A command is reissued with its original ID when the acceptance result is
    uncertain.