fix(deploy+cli): review findings — honest CLI timeouts, watermark-complete staleness, phase-2 staging, lock-safe cancellation

Six adversarial-review findings, each verified against the code first.

F1 (HIGH) CLI HttpClient capped every call at min(30s, caller timeout),
silently truncating deploy site's 5-minute BulkDeployTimeout and the
5-minute bundle export/preview/import calls — which printed a fake
"504 Request timed out" while the server kept working. HttpClient.Timeout
is now Timeout.InfiniteTimeSpan (the per-call CTS is the single overall
deadline, connect included) with the connect phase bounded separately on
SocketsHttpHandler.ConnectTimeout. The env override is renamed to
SCADABRIDGE_HTTP_CONNECT_TIMEOUT_SECONDS to match its new meaning.

F2 (HIGH) StaleInstanceProbe's process-static memo served stale hashes
because nothing bumped the watermark on three paths:
  (a) BundleImporter commits through the raw DbContext, so no import ever
      moved the watermark — a second import overwriting the same template
      could be OMITTED from ImportResult.StaleInstanceIds. It now bumps
      once per apply ATTEMPT: after the commit, and after the rollback too
      (the probe runs pre-commit, so a rolled-back attempt leaves memos for
      state that never landed; bumping on both paths is the simplest
      correct shape, versus threading transaction awareness through a
      process-static cache).
  (b) CollectWatermarkBumps' default: arm silently no-op'd, contradicting
      its own doc. It now sets unattributed=true — an over-broad bump costs
      extra work, a missed one produces stale work.
  (c) DataConnection edits route through SiteRepository.SaveChangesAsync,
      which had no watermark at all, yet Protocol/Primary+Backup config/
      FailoverRetryCount are revision-hash inputs. It now bumps (BumpAll —
      a connection has no owning template) after a commit that touched one.

F3 (MED) CLI TemplateTableProjection read child ARRAYS, but ListTemplates
now returns database-projected TemplateSummary rows, so template list
printed all zeros. It now prefers the *Count scalars and falls back to
array length (template get still returns full entities). --detail help
text and README corrected: a listing cannot yield definitions, so --detail
renders the raw summary payload and template get --id is the full dump.

F4 (MED) DeploySiteAsync staged every PendingDeployment in phase 1 against
a 5-min TTL while phase 2 reached them one batch at a time, so tail
instances' fetch tokens could expire before their command was sent.
Staging moved into phase 2, immediately before each send; prepare keeps
its flatten/validate/record work. The staging write is the phase's only
repository touch and is serialised behind a 1-permit semaphore, so the
non-thread-safe DbContext constraint holds and the sends stay concurrent.

F5 (MED, latent) DeploySiteAsync leaked every held operation lock if
cancelled — a wedged per-instance semaphore is permanent for the process.
Phase 2 no longer throws (cancellation is recorded as a per-instance
outcome so phase 3 still runs), and an escape from phase 1 or 3 now
unwinds every unfinalised entry: Failed status + lock release.

F6 (LOW) ScriptCompileVerdictCache's promotion wrote hot directly,
bypassing SegmentCapacity (true ceiling 3x against a documented 2x).
Promotion now goes through Store, keeping generational semantics; _hot
and _cold are volatile.

Tests: CLI 396, DeploymentManager 133, ManagementService 494,
TemplateEngine 478, ScriptAnalysis 60, Transport 157, Transport
integration 106, ConfigurationDatabase 366 — all green, 0 build warnings.
The F2/F4/F5 regression tests were each confirmed to FAIL with their fix
reverted.

tests/ZB.MOM.WW.ScadaBridge.DeploymentManager.Tests/DeploySiteAsyncTests.cs

@@ -1,3 +1,5 @@
+using System.Collections.Concurrent;
+using System.Diagnostics;
 using Akka.Actor;
 using Akka.TestKit.Xunit2;
 using Microsoft.Extensions.Logging.Abstractions;
@@ -209,6 +211,124 @@ public class DeploySiteAsyncTests : TestKit
         Assert.Contains("not found", result.Error);
     }
 
+    /// <summary>
+    /// A <c>PendingDeployment</c>'s fetch token expires
+    /// <c>PendingDeploymentTtl</c> after the row is STAGED, so any delay between
+    /// staging and sending is dead time burned off the token's life. Staging the
+    /// whole batch up front in phase 1 made that delay grow with batch size — the
+    /// tail instances' tokens could expire before their command was ever sent, and
+    /// the site's fetch then 404s.
+    ///
+    /// <para>
+    /// This pins the fix: every instance's <c>RefreshDeploymentCommand</c> must
+    /// arrive at the site carrying a FRESH <c>Timestamp</c> (the staging instant),
+    /// regardless of how long the batch ahead of it took. Run serially with a slow
+    /// site so the batch takes far longer than the freshness bound being asserted —
+    /// under the old shape the last instance's token would already be ~2 s old.
+    /// </para>
+    /// </summary>
+    [Fact]
+    public async Task DeploySiteAsync_StagesEachTokenImmediatelyBeforeItsOwnSend()
+    {
+        const int instanceCount = 20;
+        var perSendDelay = TimeSpan.FromMilliseconds(100);
+        ArrangeInstances(instanceCount);
+
+        var ages = new ConcurrentBag<TimeSpan>();
+        var commActor = Sys.ActorOf(Props.Create(() => new TokenAgeRecordingSiteActor(ages, perSendDelay)));
+
+        // Parallelism 1 makes the batch strictly serial, so the accumulated lag a
+        // front-loaded staging phase would produce is at its largest.
+        var service = CreateService(commActor, maxParallelism: 1);
+
+        var sw = Stopwatch.StartNew();
+        var result = await service.DeploySiteAsync(SiteId, "admin");
+        sw.Stop();
+
+        Assert.True(result.IsSuccess);
+        Assert.Equal(instanceCount, result.Value.SuccessCount);
+        Assert.Equal(instanceCount, ages.Count);
+
+        // The batch really did take a long time — otherwise the freshness assertion
+        // below would pass vacuously.
+        Assert.True(sw.Elapsed > TimeSpan.FromMilliseconds(1500),
+            $"the batch completed in {sw.ElapsedMilliseconds} ms; too fast to prove token freshness");
+
+        // ...yet no token was stale when its command reached the site.
+        var oldest = ages.Max();
+        Assert.True(oldest < TimeSpan.FromMilliseconds(500),
+            $"a fetch token was already {oldest.TotalMilliseconds:F0} ms old on arrival — " +
+            "staging is not tracking the send.");
+    }
+
+    /// <summary>
+    /// Cancelling mid-batch must not leak operation locks. Phase 1's
+    /// <c>ThrowIfCancellationRequested</c> escapes <c>DeploySiteAsync</c> while every
+    /// already-prepared deployment still holds its per-instance lock — and
+    /// <c>OperationLockManager</c> hands out real semaphores, so an undisposed handle
+    /// wedges that instance against every future mutating command for the life of
+    /// the process. Their records must also be finalised as Failed rather than left
+    /// InProgress.
+    /// </summary>
+    [Fact]
+    public async Task DeploySiteAsync_CancelledMidPrepare_ReleasesEveryLock_AndFailsPreparedRecords()
+    {
+        ArrangeInstances(6);
+
+        using var cts = new CancellationTokenSource();
+
+        // Cancel while preparing the third instance: the first two are fully
+        // prepared and holding locks when the loop's next cancellation check throws.
+        _pipeline
+            .FlattenAndValidateAsync(3, Arg.Any<CancellationToken>(), Arg.Any<bool>(), Arg.Any<FlattenSession?>())
+            .Returns(_ =>
+            {
+                cts.Cancel();
+                var config = new FlattenedConfiguration { InstanceUniqueName = "Inst-03" };
+                return Result<FlatteningPipelineResult>.Success(
+                    new FlatteningPipelineResult(config, "sha256:3", ValidationResult.Success()));
+            });
+
+        var commActor = Sys.ActorOf(Props.Create(() =>
+            new ThrottledSiteActor(new ConcurrencyTracker(), slowInstanceName: null, slowDelay: TimeSpan.Zero)));
+
+        var service = CreateService(commActor, maxParallelism: 2);
+
+        await Assert.ThrowsAnyAsync<OperationCanceledException>(
+            () => service.DeploySiteAsync(SiteId, "admin", cts.Token));
+
+        Assert.Equal(0, _lockManager.TrackedLockCount);
+
+        // No prepared deployment may be left InProgress.
+        await _repo.Received().UpdateDeploymentRecordAsync(
+            Arg.Is<DeploymentRecord>(r => r.Status == DeploymentStatus.Failed),
+            Arg.Any<CancellationToken>());
+    }
+
+    /// <summary>
+    /// Answers every <c>RefreshDeploymentCommand</c> after a fixed delay, recording
+    /// how old each command's staging <c>Timestamp</c> already was on arrival.
+    /// </summary>
+    private sealed class TokenAgeRecordingSiteActor : ReceiveActor
+    {
+        public TokenAgeRecordingSiteActor(ConcurrentBag<TimeSpan> ages, TimeSpan delay)
+        {
+            Receive<SiteEnvelope>(env =>
+            {
+                if (env.Message is not RefreshDeploymentCommand cmd)
+                    return;
+
+                ages.Add(DateTimeOffset.UtcNow - cmd.Timestamp);
+
+                var replyTo = Sender;
+                Context.System.Scheduler.Advanced.ScheduleOnce(delay, () =>
+                    replyTo.Tell(new DeploymentStatusResponse(
+                        cmd.DeploymentId, cmd.InstanceUniqueName,
+                        DeploymentStatus.Success, null, DateTimeOffset.UtcNow)));
+            });
+        }
+    }
+
     /// <summary>Records the peak number of simultaneously in-flight site round-trips.</summary>
     private sealed class ConcurrencyTracker
     {