feat(scripting): ScriptRunGuard quarantines runaway scripts across every seam (E1)

A timed-out script is abandoned, not stopped, and every seam re-ran it on the
next trigger, leaking one pool thread per trigger (R03:1.1, R05:2, R07:L1).
A shared ScriptRunGuard, keyed per script instance, now:

- refuses a run while that script's previous orphan is still executing
  (Bad "previous evaluation still running" + otopcua.script.run_refused);
- quarantines after 3 consecutive non-completions or an allocation-budget
  breach (sampled with GC.GetAllocatedBytesForCurrentThread; default 64 MB):
  no further dispatch, Bad quality, one Error, otopcua.script.quarantined,
  cleared on source change / redeploy / reset;
- starts the budget clock when the pool picks the run up, so starvation is
  no longer charged to the script (R07:P5), and cancels the evaluator token
  on timeout.

Wired into RoslynVirtualTagEvaluator, CalculationEvaluator (new async
EvaluateAsync; the driver's pump and timer ticks now await the run behind a
SemaphoreSlim gate) and ScriptedAlarmEngine (a non-completing predicate
holds state and annotates the condition BadInternalError). ScriptingOptions
(Scripting:MaxAllocBytesPerRun, Scripting:QuarantineAfterConsecutiveTimeouts)
carries the knobs; the Calculation driver config accepts the same two keys.

Tests: guard unit suite (incl. the 30-trigger runaway leaving one orphan with
a healthy sibling as positive control), per-seam refusal/quarantine/reset
tests. The S12 race test now uses one vtag id per loop: twelve concurrent
evaluations of ONE id is a shape production never produces and the guard
refuses by design.

Refs #734

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

src/Core/ZB.MOM.WW.OtOpcUa.Core.Scripting/TimedScriptEvaluator.cs

@@ -19,10 +19,12 @@ namespace ZB.MOM.WW.OtOpcUa.Core.Scripting;
 ///         task continues running on a thread-pool thread until the Roslyn runtime
 ///         returns. In the CPU-bound-infinite-loop case that's effectively "leaked" —
 ///         the thread is tied up until the runtime decides to return, which it may
-///         never do. Phase 7 plan Stream A.4 accepts this as a known trade-off; tighter
-///         CPU budgeting would require an out-of-process script runner, which is a v3
-///         concern. In practice, the timeout + structured warning log surfaces the
-///         offending script so the operator can fix it; the orphan thread is rare.
+///         never do. This wrapper has no memory of that orphan, so re-running the same
+///         script through it on every trigger leaks one more thread per trigger — which
+///         is why the production seams (virtual tags, Calculation, scripted alarms) run
+///         through <see cref="ScriptRunGuard"/> instead: same timeout, plus a per-script
+///         "previous run still executing" refusal and a quarantine. This class remains
+///         for callers that evaluate once (tests, the authoring preview).
 ///     </para>
 ///     <para>
 ///         Caller-supplied <see cref="CancellationToken"/> is honored — if the caller