Implements the third and final piece of the declarative master-switch
model from PR-B: a state-machine sweeper engine plus the operator's
catch-up affordance, COMPRESSION SWEEP FORCE.

State machine
-------------

DISABLED ←→ IDLE ←→ SCANNING ←→ SLEEPING

Triggers (R2.1.5 + R2.1.4):
  - master-switch direction change (off→compression, compression→
    decompression, etc.) with sweeper=enabled → reset cursor, enter
    SCANNING. Even mid-pass: the sweeper takes its direction from the
    current master switch on every cron tick.
  - sweeper config flips disabled→enabled (with master ≠ off) →
    enter SCANNING.
  - SLEEPING with `compression-active-sweeper-interval > 0` and
    interval elapsed → enter SCANNING.
  - COMPRESSION SWEEP FORCE pending → enter SCANNING regardless of
    sweeper config (operator-driven; rejected when master=off).

After a pass completes:
  - sweeper=disabled (force-pass committed mid-flight) → DISABLED.
  - sweeper=enabled, interval > 0 → SLEEPING.
  - sweeper=enabled, interval = 0 → IDLE (no periodic re-runs;
    R2.1.3 default — minimizes idle-keyspace iteration).

The cardinal correctness property: with interval=0 and no direction
change / FORCE / config flip, IDLE stays IDLE — the sweeper does NOT
loop. Verified by gtest IdleWithoutDirectionChangeStaysIdle (10 ticks
with no change, pass count remains 1).

Per-key dispatch (sweepScanCallback)
------------------------------------

Direction taken from master-switch at scan time:
  - master == compression: enqueue eligible RAW value via
    compressionEnqueueCandidate (worker pool compresses).
  - master == decompression: call compressionPermanentlyDecompress
    directly on the main thread (worker pool unused for
    drain-direction work, per R2.1.2).
  - master == off: callback unreachable (cron returns early).

Iteration is paced via tickBudgetUs() = (1_000_000 / hz) ×
compression-sweep-max-cpu-pct / 100, with a 1ms floor. Default
hz=10 + 25% pacing = 25ms/tick. The kvstoreScan loop checks
budget after every bucket; cursor + current_db persist across
ticks so a multi-tick pass resumes where it left off.

Sub-tick edge bug + fix
-----------------------

Apply hooks fire synchronously on every CONFIG SET, but the cron
polls server.compression_master_switch every ~100ms. A sequence
like compression→off→compression that completes inside a single
tick window is invisible to the cron — every observed value is
COMPRESSION, dir_chg=0 forever, no pass triggers.

Fix: compressionSweepNotifyMasterSwitchChanged() called from
applyCompressionMasterSwitch on every transition. The cron tick
ORs this edge-trigger with the polled comparison, so neither
source of edge is missed. Without this, the Tcl test
"Sweeper state transitions: interval > 0 enters sleeping after
pass" fails — earlier rapid CONFIG SET sequences (from previous
tests in the same fixture) hide the master-switch transition.

Non-functional state warning
----------------------------

master=compression + threads=0: the worker pool refuses every
enqueue. The sweeper's pass would burn CPU iterating the keyspace
while every candidate drops. Sweeper skips the pass with a
rate-limited LL_WARNING (once per minute); cursor is preserved
so a future threads>0 setting picks up where we left off.

master=decompression + threads=0 is functional — the pool isn't
used for permanent-decompress work.

COMPRESSION SWEEP FORCE
-----------------------

New subcommand. Rejected when master=off (no direction).
Otherwise sets force_pending = 1; the next cron tick consumes
the flag and transitions to SCANNING. Allowed even with
sweeper=disabled (the catch-up affordance — operators can leave
sweeper=disabled to avoid idle-keyspace iteration cost and run
SWEEP FORCE on demand).

Idempotent: multiple FORCE calls before the next cron tick
collapse into a single pass.

Verification
------------

- src/Makefile + cmake/Modules/SourceFiles.cmake registered.
- BUILD_ZSTD=yes and BUILD_ZSTD=no clean with -Werror.
- 15 new gtest cases under src/unit/test_compression_sweep.cpp;
  total 382 unit tests (was 367), all pass.
- 9 new Tcl test cases under tests/unit/type/compression.tcl;
  total 22 tests, all pass.
- Smoke test: master=off + sweeper=enabled = idle (no looping);
  master→compression triggers exactly one pass (interval=0);
  rapid compression↔decompression sub-tick toggles trigger
  one pass each (sub-tick edge fix).

Restructures S2.9 from a single bullet into the C1/C2/C3 split that
matched the actual rollout (mirrors how S2.8 was tracked). C1 and C2
already merged; C3 is this PR.

Two related changes from review discussion on PR #31:

  1. Rename compression-active-sweeper → compression-automatic-sweeper.
  2. Collapse the 4-state machine to 2 booleans + a timestamp.

The rename clarifies the config's role: it gates AUTOMATIC scheduling
(master-switch transitions, periodic re-runs). Manual FORCE bypasses
it. The original "active-sweeper" suggested "is the sweeper engine
active right now" — which under the simplified model is just
scan_in_progress, an internal flag rather than an operator-facing
config.

Touches (rename): compression-active-sweeper → compression-automatic-
sweeper across configs, struct fields, enums, INFO fields, design
doc, Tcl tests. compression-active-sweeper-interval renamed for
consistency.

Simplification
--------------

The earlier draft (4 states: DISABLED/IDLE/SCANNING/SLEEPING) ran
into a sub-tick edge bug: cron polls server.compression_master_switch
every ~100ms, but apply hooks fire synchronously per CONFIG SET. A
sequence like compression→off→compression that completes inside a
single tick window was invisible to the cron — every observed value
was COMPRESSION, dir_chg=0 forever, no pass triggered. The earlier
fix was a sweep_master_switch_changed flag set by the apply hook;
the cron consumed it as an edge signal.

This commit eliminates that whole tension by inverting control: apply
hooks **directly** mutate sweeper state. Two helpers:

  resetScanStateAndEnableOnce()    cursor=0, scan_in_progress=0,
                                   enable_once=1.  Aborts in-flight
                                   pass and schedules a fresh one.

  abortScan()                      cursor=0, scan_in_progress=0,
                                   enable_once=0.  Aborts without
                                   scheduling a replacement.

Apply hooks (compression.c → notify callbacks → these helpers):

  master-switch → off               abortScan()
  master-switch → {comp, decomp}    resetScanStateAndEnableOnce()
                                    when sweeper=enabled, else nothing
  sweeper disabled → enabled        resetScanStateAndEnableOnce()
                                    when master ≠ off, else nothing
  sweeper enabled → disabled        abortScan()
  FORCE (master ≠ off)              resetScanStateAndEnableOnce()
                                    (preempts in-flight scan; that
                                    is the user-facing semantic of
                                    "do a pass now, from scratch")

Cron tick (~25 lines, was ~110):

  if master == off: return
  if !enable_once && !scan_in_progress
     && !nextIntervalElapsed(): return
  enable_once = 0
  if !scan_in_progress: scan_in_progress = 1, log "starting"
  if master == compression && threads == 0:
      rate-limited warning, return  (cursor preserved)
  completed = runSweepBudget(master)
  if completed:
      scan_in_progress = 0
      last_completion_ms = mstime()
      passes_completed++

  nextIntervalElapsed():
      iff sweeper=enabled AND interval>0
      AND last_completion_ms != 0
      AND (now - last_completion_ms) >= interval*1000.

Boot: compressionSweepInit() arms enable_once if sweeper=enabled
and master ∈ {compression, decompression} at boot — same logic as
the disabled→enabled apply hook would do at runtime, since apply
hooks don't fire during config-load.

INFO field
----------

compression_active_sweeper_state (4 names) → compression_sweeper_
running (0/1). The original 4 names always collapsed semantically:
DISABLED/IDLE/SLEEPING all mean "not currently scanning, won't
start until a trigger". The new field reports the only state that
ever needed distinguishing — is a scan currently advancing?
External observers wanting "will a scan trigger soon?" can derive
it from compression_automatic_sweeper + compression_automatic_
sweeper_interval + compression_sweeper_running.

Tests
-----

gtest: 18 cases (was 15). Existing cases for direction-change /
FORCE / interval / threads-zero all survive (test by behavior,
not by state name); added cases for the apply-hook semantics
(SweeperEnabledKicksScan, SweeperDisabledAbortsAndDoesNotResume,
MasterChangeWithSweeperDisabledNoTrigger, InitArmsEnableOnce*).

Tcl: 22 cases (unchanged count). Field-name assertions updated
from compression_automatic_sweeper_state:idle/sleeping/disabled to
compression_sweeper_running:0. The "Sweeper: enabled + master=
compression runs exactly one pass with interval=0" test asserts
the cardinal correctness property (no looping with interval=0).

Verified clean with -Werror under both BUILD_ZSTD=yes and
BUILD_ZSTD=no.