Refine remaining components: Deployment Manager, Central UI, Site Event Logging, S&F

Deployment Manager: add deployment concurrency rules (block same-instance, allow
parallel different-instance), per-site artifact deployment status, current-only
status persistence.

Central UI: specify Blazor Server framework, real-time push updates via SignalR
for debug view, health dashboard, and deployment status.

Site Event Logging: daily retention purge, paginated queries with 500-event default,
keyword search on message/source fields.

Store-and-Forward: clarify async best-effort replication to standby with acceptable
trade-offs on failover.

Component-StoreAndForward.md

@@ -60,9 +60,10 @@ There is **no maximum buffer size**. Messages accumulate in the buffer until del
 ## Persistence
 
 - Buffered messages are persisted to a **local SQLite database** on each site node.
-- The active node persists locally and forwards each buffer operation (add, remove, park) to the standby node via Akka.NET remoting.
+- The active node persists locally and forwards each buffer operation (add, remove, park) to the standby node **asynchronously** via Akka.NET remoting. The active node does not wait for standby acknowledgment — this avoids adding latency to every script that buffers a message.
 - The standby node applies the same operations to its own local SQLite database.
-- On failover, the new active node has a complete copy of the buffer and resumes delivery.
+- On failover, the new active node has a near-complete copy of the buffer. In rare cases, the most recent operations may not have been replicated (e.g., a message added or removed just before failover). This can result in a few **duplicate deliveries** (message delivered but remove not replicated) or a few **missed retries** (message added but not replicated). Both are acceptable trade-offs for the latency benefit.
+- On failover, the new active node resumes delivery from its local copy.
 
 ## Parked Message Management