feat(chatarchive): add file locking for concurrent manifest writes

[CodeMonkeyCybersecurity]

Problem

If two eos backup chats invocations run simultaneously, both could read the same manifest and race on write, leading to data loss in the manifest.

Root Cause

No file locking on manifest.json during read-modify-write cycle in pkg/chatarchive/archive.go.

Proposed Fix

Use flock() (Unix) or LockFileEx (Windows) on the manifest file during the write phase. Go's golang.org/x/sys package provides cross-platform file locking.

Priority

P2 — low probability for a local CLI tool, but worth fixing for robustness.

Refs: pkg/chatarchive/archive.go, pkg/chatarchive/manifest.go

[CodeMonkeyCybersecurity]

SOAPIER session note (2026-03-20)

Presenting issue

• Concurrent manifest writes remain a valid follow-up from the chatarchive hardening branch refactor/chat-archive-cross-platform.

Past history

• Issue feat(chatarchive): add file locking or flock for concurrent archive runs #91 was opened after this issue with a narrower write-race description and more explicit acceptance criteria for manifest read-merge-write locking.

Objective assessment

• Reviewed pkg/chatarchive/archive.go and pkg/chatarchive/manifest.go. Manifest writes are atomic per write, but the overall read-merge-write cycle is still not protected by a lock.

Analysis

• feat(chatarchive): add file locking for concurrent manifest writes #85 and feat(chatarchive): add file locking or flock for concurrent archive runs #91 describe the same underlying gap. feat(chatarchive): add file locking or flock for concurrent archive runs #91 is currently the more specific problem statement; feat(chatarchive): add file locking for concurrent manifest writes #85 remains the original tracker.

Plan

• Keep both issues cross-linked until implementation starts, then consolidate closure semantics in the PR so one closes and the other references the shipped fix.