[BUG] Windows Desktop: main process permanently stops writing main.log once it hits the 10 MB rotation cap mid-run

Environment

• Claude Desktop 1.12603.1, Windows 11, MSIX-packaged (Claude_pzs8sxrjxfjjc), CCD 2.1.170
• Logs at %APPDATA%\Claude\logs (virtualized into the package LocalCache)

What happens

When the running app's main.log reaches the ~10 MB rotation cap mid-session, the main process stops writing log lines entirely. Nothing is logged again, to main.log or anywhere else, until the app is restarted. Sessions and the renderer keep working fine -- only file logging dies, silently.

Measured from tonight's occurrence:

• main1.log (the archived main.log) ends mid-activity at 2026-06-13 00:39:30, size 10,488,191 bytes. The last lines are normal traffic: a message send, a "Mapping internal session ... to CLI session ..." line, a setFocusedSession, a WarmLifecycle line. It just stops.
• The app was NOT restarted: it had been running since Jun 12 16:15, and two secondary launches at 00:59 and 01:14 logged "Not main instance, returning early" into the fresh main.log -- proving a main instance was alive holding the single-instance lock, and that the new main.log is writable.
• The user kept working for 80+ minutes after 00:39 (multiple sessions, tab switches, message sends, hook activity). Zero lines from the main process in any log file in that window. The fresh main.log contains ONLY the two secondary-instance startup bursts (1,510 bytes total).

The previous log generation shows the same signature: main2.log ends 2026-06-05 04:21:08 at 10,486,937 bytes (the cap), and logging resumes only at 05:03:19 with a fresh "Starting app" (1.11187.1, so under the prior version). Consistent with the same failure: the gap between cap-hit and next app start is always silent, and every log generation begins with "Starting app" -- there is no evidence in-place rotation has ever completed.

Expected

In-place rotation: archive main.log -> main1.log, create a fresh main.log, keep logging.

Suspected cause

The archive/reopen step in the main process fails under MSIX filesystem virtualization (rename of the open log file inside the virtualized %APPDATA% view?) and the file transport dies silently instead of recovering. At the next app start the init-time rotation succeeds, which is why logging only ever resumes with "Starting app".

Impact

• All main-process diagnostics from the affected window are lost -- exactly the periods bug reports need.
• External tooling that follows main.log (session-focus / session-mapping events) goes blind until restart. That is how this was noticed: a context gauge that tails main.log froze on stale data at the exact moment the log hit 10 MB.

Repro

1. Windows, MSIX install. Let main.log grow to the 10 MB cap during a single app run (no restart in between).
2. Observe: no further lines in any log file; the fresh main.log is only created/written by a NEW instance (secondary launch or restart).

Log files available on request.