[marcmy]

Summary

• record the exact compression algorithm selected for a successful manual queue run
• await watcher-state updates before continuing, rather than firing an unobserved async update
• preserve a watched folder's configured target during routine scans and background recompression
• stop the background compactor from replacing its target based on mixed on-disk algorithms
• replace numeric Max() detection with a proper dominant-mode helper for folders whose target is not yet known
• preserve the existing manual-uncompress behavior

Root cause

WOFCompressionAlgorithm stores Windows' native API identifiers, not a strength ranking: LZX is 1, XPRESS8K is 2, and XPRESS16K is 3. The watcher used Max() over detected file algorithms, so any remaining XPRESS16K file caused the folder to be recorded as X16 even after an LZX run.

Mixed algorithms are normal because the compressor deliberately skips files that are already on the target mode, are no larger than a cluster, or match excluded-file rules. The watcher's CompressionLevel is also the target passed into future background recompression, so the stale X16 value affected behavior rather than only the badge.

Validation

• strict Windows x64 restore and self-contained publish passed with TreatWarningsAsErrors=true
• packaging and artifact upload passed
• supply-chain audit passed

Runtime test plan

1. Start with a watched folder whose badge shows X16.
2. Add it to the compression queue, select LZX, and complete compression.
3. Confirm the watcher badge changes to LZX.
4. Modify or add files in that folder and run the watcher again.
5. Confirm the watcher retains LZX and uses LZX for automatic recompression.
6. Confirm manually uncompressing a watched folder still updates its watcher state appropriately.