fix(deployment): bulk-deploy up-to-date pre-filter uses batch hash/status reads and the operation's shared flatten session; completion log reports pre-filter cost (review 2026-10-21 04/P1)

docs/requirements/Component-DeploymentManager.md

@@ -177,6 +177,18 @@ deliberately stopped; they are reported in the summary's `SkippedInstances` with
 the reason "Disabled — bulk deploy preserves disabled state; deploy individually
 to re-enable", and the single-instance deploy remains the explicit re-enable path.
 
+**Up-to-date instances are skipped too (unless `force`), at batch cost.** The
+pre-filter reads the deployed-hash projection (`GetDeployedRevisionHashesAsync`) and
+the Enabled candidates' current deployment records
+(`GetCurrentDeploymentStatusesAsync`) ONCE each — no snapshot `ConfigurationJson`
+is materialised — and re-hashes each candidate with the hash-only flatten
+(`IFlatteningPipeline.ComputeRevisionHashAsync`) on the bulk operation's **one
+shared `FlattenSession`**, the same session phase 1 then prepares on, so a template
+chain is walked once across both (review 2026-10-21 04/P1; previously each probe
+built a private session, loaded the tracked snapshot and queried the status per
+instance). The completion log reports the pre-filter's probe count, elapsed time
+and chain loads alongside the totals.
+
 **Reconciliation is bounded per batch.** Phase 1 is serial, so an unreachable site
 would otherwise cost the batch one full communication-layer `QueryTimeout` (30 s)
 per instance before a single deploy was sent — hours for a large site, past the
@@ -259,10 +271,8 @@ The system maintains two views per instance:
 These are compared to determine staleness and generate diffs.
 
 The comparison path is **hash-only by design**. When the Template-Derived
-Configuration is re-flattened for a comparison (the Deployments comparison page)
-or for the Transport stale-instance probe
-(`IStaleInstanceProbe.GetCurrentRevisionHashAsync`, used per-instance across a
-bundle import), the pipeline is invoked with `validateScripts: false`, which
+Configuration is re-flattened for a comparison (the Deployments comparison page),
+the pipeline is invoked with `validateScripts: false`, which
 skips **only** the expensive Roslyn script-compilation stage
 (`ValidationService.ValidateScriptCompilation` — a non-collectible assembly load
 per script). Structural and semantic validation still run. These read-only paths
@@ -551,6 +561,6 @@ The Deployment Manager sends the following commands to sites via the Communicati
 
 ### Authoritative staleness and bulk deadlines
 
-`StaleInstanceProbe` no longer memoizes revision hashes against process-local watermarks. Every probe starts a fresh flatten session, so a configuration edit through another central is visible to the next deployment skip decision. This trades extra flattening work for correctness across shared-database writers.
+`StaleInstanceProbe` no longer memoizes revision hashes against process-local watermarks. Every probe starts a fresh flatten session, so a configuration edit through another central is visible to the next deployment skip decision. This trades extra flattening work for correctness across shared-database writers. The probe (used per instance across a bundle import), the bulk-deploy pre-filter and the pending-updates sweep all use the hash-only `IFlatteningPipeline.ComputeRevisionHashAsync` — flatten + hash, no validation — whose hash equals `FlattenAndValidateAsync`'s, so all three agree with the deploy gate on what "stale" means. The bulk pre-filter shares its operation's session (a within-operation share, not the removed cross-operation memo).
 
 Management bulk deployment uses `LongRunningCommandTimeout` as an overall scheduling/send deadline. Cancellation stops scheduling more instances, fails unfinished eligible rows, and releases prepared operation locks. Completed and deliberately skipped outcomes remain in the response. HTTP Ask reserves an additional60 seconds for cleanup and response; the bulk CLI defers its timeout to this server-owned deadline.