v0.28.0 - a trim is not a free, and an install that is still doing it gets told

Trimming working sets is not freeing memory, and Idle Master has stopped doing it
behind your back.

The trim is off by default

At the end of every boost — and again every ten minutes for as long as the sentry
was armed — Idle Master used to squeeze every process still running and purge the
standby list. That number went in the log as memory freed. It was not.

A trim evicts pages from processes that are still running and still wanted. The
clean ones go to the standby list, the changed ones head for the pagefile, and
every one of them faults back the moment you touch the app again. Purging standby
on top turns those cheap returns into reads from disk — for memory that was
already available to whatever asked for it next, because standby is available
memory; the allocator reclaims it on demand without being asked.

So the megabytes it reported were never really freed, and the bill arrived later
as a stutter when you went back to whatever had been squeezed. Every sweep. On a
machine that exists to hand Sunshine a steady frame, that is a hitch you would
blame on the network.

TrimWorkingSets and ClearStandbyList are now 0.

Three ways to trim, all of them somebody's decision

• Trim RAM now — the button on the window. Always runs, whatever the settings
  say. Worth a click right before you launch something big: you are abandoning
  those apps anyway, so the fault cost is paid later, for nothing.
• TrimWhenFreeBelowMb — runs even with TrimWorkingSets=0. Being genuinely
  short of memory is the one moment evicting pages beats keeping them.
• TrimWorkingSets=1 — the old behaviour, boost and the sentry clock
  included, for anyone who wants it back.

The flag used to sit inside TrimAll, which meant turning it off silently broke
the button too. It now gates the automatic callers only.

The headline stops summing two different things

Memory a kill released is gone and stays gone until you open the app on purpose.
Memory a trim "freed" is on its way to disk. Adding them together made the bigger
number and the worse claim, so a boost now reports a line each - what was
released by closing things, and separately, if you asked for a trim, what was
squeezed out of processes that are still running and will want it back.

If you are updating, you get told once

An update keeps your idlemaster.ini exactly as it found it — which is the
right promise to keep, and also means a machine that has been running Idle Master
for a while carries TrimWorkingSets=1 forward and goes on trimming as if nothing
had changed.

So it gets told, once, on the same frosted pane the theme picker uses: what it has
been doing, why that stopped being the default, and two buttons — Stop trimming
automatically, which writes TrimWorkingSets=0 and ClearStandbyList=0 into
the ini line by line so every comment in that file survives, or Leave it as it
is, which changes nothing.

Either answer writes TrimNotice=1 and the pane never comes back. Being asked is
what gets remembered, not which way it went — a prompt that reappears every start
is a nag, and the whole point of the change was to stop doing things to your
machine that you did not ask for. A fresh install ships TrimNotice=1 and never
sees it; neither does a machine that had already turned trimming off by hand.

Also in this release

Trash once means the whole session (v0.26.0). "Trash once" closed the thing
and put its name on a 30-minute backoff — so half an hour later the same process
was back, asking the same question about the thing you had just trashed. The four
toast answers now mean four different lengths of time:

	lasts	written
Keep it	until Idle Master restarts	nothing
Always keep	forever	[protect]
Trash once	until Idle Master restarts	nothing
Always trash	forever	[ask.never] + [boost.kill]

"Always trash" also used to write [boost.kill] only when the name was on no list
at all, so a name answered from an idle watch that was only on the idle list
survived the next boost. It goes on the boost list whenever it is not there
already now.

The respawn brake is untouched: a name that comes back SentryRespawnLimit times
is still rested for SentryBackoffMinutes, and the log still says so.