perf(virtual-browser): tune Selkies encoding defaults for UI workloads

[june-hua]

Sets five Selkies encoding defaults suited to a text/UI workload rather than the full-motion default.
Stacks on #463. One file, +25 lines.

First, a correction to the premise

I started from the assumption that a still page was being encoded as full-motion video and that
enabling damage-based encoding would be the big win. That assumption was wrong. This image runs
the Wayland damage-tracking path (PIXELFLUX_WAYLAND=true is baked in), which already spins the
encoder down to zero when nothing changes. Per LinuxServer: "we only encode the frames that need to
be sent."

So idle cost was already low, and there is no damage-encoding switch to flip. The remaining savings
are in motion periods and in the audio pipeline, which is a constant cost paid even in
silence. The knobs that would tune damage behaviour directly (paint_over_trigger_frames,
damage_block_threshold, damage_block_duration) are hardcoded at 15/10/20 and exposed by no env
var.

What's set

Variable	Value	Why
SELKIES_FRAMERATE	20	Default is 60, not 30. ~3x lower peak encode during motion; imperceptible for text/UI.
SELKIES_H264_CRF	28	Trims bitrate during motion.
SELKIES_USE_PAINT_OVER_QUALITY	true	Sharpens the still frame after motion settles.
SELKIES_AUDIO_ENABLED	false	Removes pcmflux capture + Opus encode entirely — a constant cost otherwise paid in silence.
SELKIES_MICROPHONE_ENABLED	false	Not used by this template.

Audio and mic are set unlocked, so they can be re-enabled per deployment without a rebuild.

Verified by runtime readback in the built container: framerate: (20,20), h264_crf: (28,28),
audio_enabled: (False, …), encoder: 'x264enc', no errors.

Three traps worth knowing

• A framerate range silently does nothing. 8-20 still boots at 60fps. Only a fixed value takes
  effect.
• USE_PAINT_OVER_QUALITY deactivates if H264_CRF ≤ 18 (documented precondition). 28 is safe,
  but lowering CRF later would silently disable paint-over.
• Do not add a CBR bitrate cap. Padding to a constant bitrate defeats the whole point of not
  sending an unchanged screen.

Considered and rejected

SELKIES_ENCODER=x264enc-striped — I had this as the headline change and backed it out. Full-frame is
also damage-gated so the win was largely already delivered; LSIO dropped striped from their default
deliberately ("it really only sees benefits on these older CPUs", pre-AVX2, and our VMs are modern);
and it forfeits hardware encode, since Selkies forces use_cpu=True for striped. Worth an A/B, not a
default.

Encoder preset is not tunable and needs no tuning — pixelflux bundles its own libx264 already running
ultrafast + zerolatency.

Decision needed before this leaves draft

SELKIES_FRAMERATE=20 hides the framerate slider from users. In this Selkies version a fixed
value is the only way to change the default, and setting one removes the control. If we'd rather users
keep it, drop the framerate change and treat it purely as an A/B.

Savings are unmeasured — deliberately no invented percentages. Measurement notes exist separately;
watch docker stats on the browser container, comparing a static page against sustained scrolling.

Overlaps #463's compose file; hunk placed clear of CHROME_CLI to reduce conflict with the concurrent
policy PR (#464).