docs: sync Transport/TemplateEngine/DeploymentManager specs + CLAUDE.md with the arch-review fix wave (plan 05)

#05-T25 (terminal doc sweep + deferred-decision records). Component-Transport:
scripts/ dir marked not-implemented; transported-entity list gains LockedInDerived
/ script cadence-timeout / real AreaName / native-alarm-sources (round-trip-guard
verified); LineDiffer input cap (T22); rename call-site limitation made load-bearing;
preview→apply no-optimistic-concurrency window + session cap recorded. Component-
TemplateEngine: alarm-override granularity corrected (only TriggerConfig+PriorityLevel
instance-overridable, NOT Description/OnTriggerScript). Component-DeploymentManager:
OperationLockManager per-node invariant (routing rejection owned by plans 01/07) +
post-success audit isolation (T17). CLAUDE.md #24 blurb + Transport bullet updated
(trust gate, severity split, ArtifactDiff identity fix, T8 fidelity fixes, T14
plan-06 handoff). Component-ScriptAnalysis fifth-call-site + deny-list already synced
in T20/T21. No ../scadaproj/CLAUDE.md change needed — no wire-relationship/stack shift.

Claude-Session: https://claude.ai/code/session_01MtdgwpEeCUn6cUA5f1LMPj

docs/requirements/Component-DeploymentManager.md

@@ -91,6 +91,16 @@ All mutating operations on a single instance (deploy, disable, enable, delete) s
 - Only one mutating operation per instance can be in-flight at a time. A second operation is rejected with an "operation in progress" error.
 - **Different instances**: Operations on different instances can proceed **in parallel**, even at the same site. Each tracks status independently. This supports the bulk "deploy all out-of-date instances" operation efficiently.
 
+> **`OperationLockManager` scope invariant (recorded decision, arch-review 05).** The
+> per-instance locks are **per-node, in-memory**. Mutual exclusion therefore holds only
+> because management traffic reaches a single node — the **active** central node, via
+> Traefik's active-node routing. A direct mutation sent to the **standby** central port
+> would take a *different* in-memory lock and could race the active node. Structurally
+> rejecting mutating operations on the non-active node (so the standby can never accept
+> them) is **not** owned here — it belongs to the cluster-routing / management-surface
+> plans (01/07). The Deployment Manager records the invariant and assumes single-active-node
+> delivery; it does not itself enforce node identity.
+
 ### Allowed State Transitions
 
 | Current State | Deploy | Disable | Enable | Delete |
@@ -119,6 +129,7 @@ When deploying artifacts (shared scripts, external system definitions, etc.) to
 
 - Only the **current deployment status** per instance is stored in the configuration database (pending, in-progress, success, failed).
 - No deployment history table — the audit log (via IAuditService) already captures every deployment action with who, what, when, and result.
+- **Post-success audit isolation (arch-review 05, Task 17):** the audit write that records a successful deployment runs **outside** the deployment's own success path — an audit-write failure (DB blip, transient error) is logged and swallowed, and NEVER flips a genuinely-successful deployment to failed or triggers a spurious rollback. Audit is best-effort; the deployment's own apply result is authoritative (mirrors the system-wide "audit-write failure never aborts the user-facing action" rule).
 - The Deployment Manager uses current status to determine staleness (is this instance up-to-date?) and display deployment results in the UI.
 
 ## Deployment Scope