docs(siteruntime): compile gate is synchronous by design; Expression alarms share the bounded script pool (plan R2-03 T7)

docs/requirements/Component-SiteRuntime.md

@@ -96,7 +96,7 @@ flowchart TD
 
 > **Startup config load is retried (S5)**: step 1's deployed-config read is best-effort against local SQLite, which can transiently fail (locked/busy). A failed load must **not** leave the site as a silent zero-instance node — it is re-attempted on a fixed interval until it succeeds, then the retry self-cancels.
 
-> **Per-instance compilation during staggered startup (P6, follow-up)**: the Roslyn compile of each instance's scripts still runs inside Instance Actor start during staggered startup; moving it off-thread is a deferred optimization (it affects failover time-to-recover only, not correctness).
+> **Per-instance compilation during staggered startup (P6, follow-up)**: the Roslyn compile of each instance's scripts still runs inside Instance Actor start during staggered startup; moving it off-thread is a deferred optimization (it affects failover time-to-recover only, not correctness). As of the round-2 hardening, a process-wide compile cache dedupes identical script bodies within a node's process lifetime (the deploy gate's compile is reused by Instance Actor start), shrinking the recompile cost; the *first* compile after process start still runs inside Instance Actor start, so the deferral stands.
 
 ### Deployment Handling
 - Receives flattened instance configurations from central via the Communication Layer.
@@ -238,6 +238,7 @@ When the Instance Actor is stopped (due to disable, delete, or redeployment), Ak
   - **Range Violation**: Value is outside the allowed min/max range.
   - **Rate of Change**: Value change rate exceeds the defined threshold over a configurable time window. Direction filter (rising / falling / either) restricts which side of the rate triggers.
   - **HiLo**: Multi-setpoint level alarm with up to four configurable setpoints (LoLo, Lo, Hi, HiHi). Any subset may be configured. Each setpoint may carry its own priority that overrides the alarm-level priority for that band.
+- **Expression** trigger evaluation runs on the bounded script-execution thread pool shared with script bodies (and Expression *script* triggers): scheduler saturation — e.g. stuck scripts occupying all threads — delays Expression alarm transitions site-wide until a thread frees. This is a deliberate trade-off (evaluation no longer blocks dispatcher threads; per-actor coalescing bounds queue growth) and the scheduler gauges + stuck-script watchdog make the saturated state visible.
 - For binary trigger types (ValueMatch / RangeViolation / RateOfChange), when the condition is met and the alarm is currently in **normal** state, the alarm transitions to **active**:
   - Updates the alarm state on the parent Instance Actor (which publishes to the Akka stream).
   - If an on-trigger script is defined, spawns an Alarm Execution Actor to execute it.
@@ -486,7 +487,7 @@ Per Akka.NET best practices, internal actor communication uses **Tell** (fire-an
 ### Script Compilation Errors
 - If script compilation fails when a deployment is received, the entire deployment for that instance is **rejected**. No partial state is applied.
 - The failure is reported back to central as a failed deployment.
-- **Enforced by a site-side pre-compile validation gate (S3)**: before the Instance Actor is created or the config persisted, the Deployment Manager compiles **all** of the instance's scripts, alarm on-trigger scripts, and trigger expressions **off-thread**; any compile failure rejects the deployment with the collected compile errors. This makes the deployment result honest even if central's pre-deployment validation was bypassed or skew let a bad artifact through.
+- **Enforced by a site-side pre-compile validation gate (S3)**: before the Instance Actor is created or the config persisted, the Deployment Manager compiles **all** of the instance's scripts, alarm on-trigger scripts, and trigger expressions **synchronously, as a pure prefix step of the deploy handler on the singleton's actor thread** — deliberately not off-thread, because piping the verdict back to self would reorder concurrent deploys against delete/disable and break the redeploy-supersede mailbox-FIFO ordering (see the in-code rationale in `DeploymentManagerActor.HandleDeploy`); unchanged script bodies hit the process-wide compile cache, so the gate recompiles only genuinely new code. Any compile failure rejects the deployment with the collected compile errors. This makes the deployment result honest even if central's pre-deployment validation was bypassed or skew let a bad artifact through.
 - Note: Pre-deployment validation at central should still catch compilation errors before they reach the site; the site gate is the authoritative backstop.
 
 ---

src/ZB.MOM.WW.ScadaBridge.SiteRuntime/Deployment/DeployCompileValidator.cs

@@ -14,8 +14,11 @@ namespace ZB.MOM.WW.ScadaBridge.SiteRuntime.Deployment;
 /// deployment; no partial state is applied).
 ///
 /// Because it holds no actor state and only calls the (stateless)
-/// <see cref="ScriptCompilationService"/>, it is safe to run off the singleton
-/// mailbox on a <c>Task.Run</c> thread — the deploy path never blocks on Roslyn.
+/// <see cref="ScriptCompilationService"/>, it is pure and thread-safe; the Deployment
+/// Manager nevertheless invokes it <em>synchronously on the singleton's actor thread</em>
+/// as a pure prefix step, preserving mailbox-FIFO deploy ordering (see
+/// <see cref="Actors.DeploymentManagerActor.HandleDeploy"/>). Compiles of unchanged
+/// script bodies are deduped by the process-wide compile cache.
 /// </summary>
 public sealed class DeployCompileValidator
 {