screen_recorder: add encoder setting with CPU fallback

[deeplakes]

Summary

Adds an encoder setting (gpu / cpu, default gpu) to the Screen Recorder
plugin, and always passes -fallback-cpu-encoding yes to gpu-screen-recorder
for both recording and the replay buffer.

Motivation

On GPUs with no hardware video encoder at all (Asahi/Apple Silicon GPUs, some
VMs), gpu-screen-recorder's VAAPI probe fails outright:

gsr error: gsr_get_supported_video_codecs_vaapi: vaInitialize failed
gsr error: selected video codec h264 is not supported by your hardware

The recording aborts with no output file, and the plugin currently exposes no
way to force software encoding. gpu-screen-recorder already supports this
via -encoder cpu / -fallback-cpu-encoding yes; the plugin just never wired
it up.

• -fallback-cpu-encoding yes is added unconditionally: if a hardware
  encoder fails at runtime for any reason, the recording degrades to software
  encoding instead of aborting. This is a no-op improvement for everyone with
  working hardware encoding.
• encoder = cpu additionally skips the hardware probe entirely, for
  hardware where it always fails anyway.

Default stays gpu so existing behavior is unchanged for users with a
working hardware encoder.

Type of Change

• Bug fix
• New feature

Testing

• noctalia plugins lint screen_recorder — 0 errors, 0 warnings
• python3 .github/workflows/validate-plugins.py --root . — validated 12 plugin manifest(s)
• Manually verified end-to-end on the hardware this fixes: an Apple M2 MacBook
  running Asahi Linux + niri + Noctalia. Before the fix, starting a recording
  produced the vaInitialize failed error above and no output file. After
  setting encoder = cpu, a portal-mode recording completed successfully to
  ~/Videos/Recordings.

Manual Coverage

• Tested on Niri

Checklist

• This PR is ready for review, or it is marked as Draft.
• I self-reviewed the changes.
• I added or updated translations/en.json, or this PR adds no new user-facing strings.
• I did not edit non-English translation files unless this PR is explicitly for translation tooling, an import/export sync, or a maintainer-requested locale change.

Additional Notes

Bumped plugin.toml version from 1.2.2 to 1.3.0 (new backward-compatible setting).

[ItsLemmy]

• [P1] Prevent non-H.264 codecs when CPU encoding is selected — screen_recorder/recorder_service.luau:208
  buildEncoderFlags() adds -encoder cpu, but both command builders still pass the configured video_codec unchanged via -k {codec}.

  The manifest permits hevc, av1, vp8, and vp9, while gpu-screen-recorder supports CPU encoding only for H.264. Selecting encoder = cpu with any other codec therefore causes recording and replay startup to fail.

  Fix by either rejecting/clearly preventing incompatible combinations or forcing H.264 when CPU encoding is selected.

  Update the UI escription as needed; “CPU encoding always works” is currently inaccurate.

  Upstream option documentation: https://manpages.debian.org/testing/gpu-screen-recorder-cli/gpu-screen-recorder.1.en.html#encoder