[KnifeLemon]

Refs #957

Filee's memory while waiting in the tray is almost all native, not managed. This PR removes what could safely go and makes the next Linux log show the split.

Nothing here was measured on Linux (no WSL distribution or Docker on the machine). Every number below is Windows x64, Release, English UI, from one or two runs. The Linux changes are compiled (-r linux-x64) but have never been run.

What fills idle memory (Windows)

• Managed heap: 3-7 MB in every idle run. So GC and JIT settings have little to work on.
• Embedded fonts: about 45 MB private and 82 MB of working set. Avalonia opens all 18 files at start, and SKTypeface.FromStream copies each into native memory (read from its IL, so this also applies on Linux).
• GPU stack: about 38-48 MB private right after a tray start, and about 100 MB after the main window has been open (private 192 MB with the GPU, 86 MB with FILEE_RENDERING=software). Avalonia's GLX setup also creates its context at start (read from its IL).

Changes

• Fonts on demand (FileeFontCollection): Noto Sans first, the rest together at the first letter it lacks. They aren't read one by one because Avalonia scores every font read so far, so a partial set would change the font it picks. A test compares the result against the eager collection, starting from a new collection for each letter and weight.
• Trim after a tray start: nothing asked for a trim before unless a job finished or a window closed.
• Aggressive collection in the trim: the old comment said forced collections decommit empty regions. Measured, they don't.
• Linux: malloc_trim in the trim, looked up by name in libc.so.6, so musl skips it.
• Linux log line: own (USS), resident, anonymous, managed heap and committed, malloc used and free. Process.PrivateMemorySize64 reads VmData there, which isn't what smem shows.
• Linux FILEE_RENDERING=software (X11), opt-in. I left the default alone because I can't test the donut's animation on Linux.
• Closing the crop, image edit and PDF page windows now requests a trim, as the other tool windows do.

On Windows and macOS the fonts, the tray-start trim, the aggressive collection and the trim on closing those windows also apply. The Windows trim log line gains the committed size.

Measured (Windows)

Scenario	main	this PR
Tray start, 20 s, working set / private	215 / 114 MB	133 / 73 MB
Tray start, 60 s, working set / private	213 / 112 MB	18 / 63 MB
Main window opened, then closed to the tray, private	188 MB	185 MB
Same, Korean UI, private	not comparable (see below)	189 MB

Freeing a 544 MB managed heap in a separate probe, then trimming:

Collection	Committed after	Private after	Time
Forced (old)	422-434 MB	436-448 MB	about 80 ms
Aggressive (new)	0 MB	9 MB	146-188 ms

In one of the two forced runs, committed had dropped to 88 MB three seconds later; in the other it stayed at 422 MB.

The Korean baseline run isn't comparable: its window closed late, so it was sampled before the trim. An earlier Korean-UI run of main measured 188-190 MB after the trim.

Tried at a tray start, no effect beyond noise (about 3 MB), so not changed: ReadyToRun, TieredPGO=0, TieredCompilation=0, gcConcurrent=0, GCConserveMemory=5, GCgen0size. ReadyToRun also made no difference after the window had been open, and it adds 44 MB to the publish folder.

Limits

• The font saving ends at the first "→". Noto Sans lacks U+2192, and in the English run that letter triggered the read while the What's New window opened. That's why the window row barely moves. Other windows that show the arrow will do the same, and the fonts then stay for the rest of the run. A small symbol font placed after Noto Sans might keep the CJK fonts out for Latin UIs; that's a separate decision.
• Not measured at all: the malloc_trim effect, and everything else in real Linux numbers. The new log line is there to get them from the reporter.

Left out

• Limiting malloc's arenas: unmeasured on Linux, and it could slow in-process native work such as libvips. We're asking the reporter to compare with MALLOC_ARENA_MAX=2 first, and will decide from that number.
• Lower SkiaOptions.MaxGpuResourceSizeBytes: 16 MB saved about 19 MB private, but a low cap risks re-uploading large previews every frame.
• Creating the toast window on first use: about 9 MB private, one run; needs the toast's job subscription reworked.
• AnnotationFonts: still keeps its own copies of the bold faces after the first label.

Tests

• FileeFontCollectionTests, MemoryTrimmerTests, NativeMemoryRenderTests, LocalizationResourceTests and MainWindowReleaseTests pass on Windows.
• LinuxMemoryTests: the parsing passes here. The glibc test is skipped on Windows, so CI on Linux will be its first run.
• dotnet format --verify-no-changes is clean on the changed files.

🤖 Generated with Claude Code