Harden bridge History thread-safety with comprehensive HistoryLock coverage

[PureWeen]

Follow-up to #214. Addresses review findings around History thread-safety, server-side enforcement, retry resilience, and lock scope correctness.

Changes

1. Thread-safe History access via HistoryLock

• Added HistoryLock + GetHistorySnapshot() to AgentSessionInfo — a single lock object and snapshot method for all callers
• Locked all background-thread writes in CopilotService.Bridge.cs: OnContentReceived, OnToolStarted, OnToolCompleted, OnImageReceived, OnReasoningReceived, OnReasoningComplete, and SyncRemoteSessions Clear+AddRange
• WsBridgeServer.SendSessionHistoryToClient uses GetHistorySnapshot() instead of bare ToArray()
• UnreadCount uses GetHistorySnapshot() instead of try/catch

2. Widened lock scopes to cover all mutations (Review Fix)

• ToolExecutionCompleteEvent: Extended lock to cover all histToolMsg property mutations (MessageType, ImagePath, Caption, IsComplete, IsSuccess, Content) — previously the reference escaped the lock scope
• ApplyReasoningUpdate: Extended lock to cover all reasoningMsg property mutations (ReasoningId, IsComplete, IsCollapsed, Timestamp, MergeReasoningContent)
• CompleteReasoningMessages: Moved property mutations (IsComplete, IsCollapsed, Timestamp) inside the lock block — previously captured reference list was mutated outside lock

3. Server-side history cap (MaxHistoryPayloadMessages = 500)

• SendSessionHistoryToClient enforces a server-side max regardless of client-requested limit
• Even LoadFullRemoteHistory (limit: null) is capped to 500 messages server-side
• Prevents unbounded WebSocket payloads

4. Retry with cap for failed history requests (Review Fix)

• SyncRemoteSessions re-requests history for sessions that were previously requested but still have no local history
• Added retry cap (max 5 attempts) to prevent infinite retry loops — previously retried unconditionally every sync cycle
• Prevents sessions from being permanently stuck showing "Loading conversation…"

5. MessageCount consistency (Review Fix)

• OnContentReceived and OnToolStarted now update session.MessageCount after History.Add inside the lock — previously only OnReasoningReceived updated it
• BuildSessionsListPayload and initial connect check use MessageCount (int field) instead of History.Count (list enumeration)

6. Avoid cross-thread History.Count reads

• Bridge event handlers use MessageCount field instead of History.Count to avoid racing with background writes

Review History

• Round 1: 6 findings identified (TOCTOU, unbounded retry, MessageCount desync, pagination, Events.cs locking, missing MessageCount)
• Round 2: All 6 original findings fixed; 5 new findings identified (lock scope too narrow in 3 handlers, unbounded retry persisted, MessageCount still stale in 2 handlers)
• Round 3: Applied fixes for all 5 remaining issues in commit Fix 5 thread-safety issues