• Folder mode is available in the Home Assistant app. The directory watcher has existed
  in the standalone service since 0.23.0, but the app never offered it: no folder options,
  frigate_url was mandatory, and /media and /share were not mounted at all — so even a
  hand-written path could not be read. Requested in #31 by a user with five Reolink cameras
  and no Frigate, uploading snapshots to /media over FTP.
• frigate_url may now be left empty. An empty URL means no Frigate: the service falls back
  to a no-op client, and the gallery, unknown review and history stay usable.
• /media is mounted read-only and /share writable — the latter only so gallery
  backups can be written there, see below. FaceID never changes or deletes what it watches,
  and no other host path is visible to the app.
• New options: folder_enabled, folder_path, folder_camera, folder_recursive,
  folder_process_existing, folder_extensions, folder_poll_interval,
  folder_settle_seconds, folder_max_frames, folder_max_people_per_file,
  folder_max_indexed_files.
• The app now refuses to start with neither input configured, and warns on start when
  folder_path does not exist inside the container — naming the two mounted roots, since a
  path the app cannot see is the likeliest mistake.
• In folder mode the camera sensor appears at startup, not only after the first
  recognition. The folder has no camera list to query, so its name is taken from the
  configuration; without that a fresh install looked like it was doing nothing.
• Home Assistant backups of the app shrink by roughly 600 MB. The recognition model
  cache was stored in every backup although it re-downloads by itself on the next start;
  backup_exclude now leaves it out. Reported in #33 with measurements: 1.1 GB compressed
  for an app whose irreplaceable data is about 11 MB.
• backup_dir is settable in the app, and /share is mounted writable for it. Pointing
  the built-in gallery backup at /share/faceid puts it where Home Assistant's own backups
  already look — a few MB for the one thing that cannot be re-created. /media stays
  read-only: it is a source, never a target.
• A backup target that cannot be written is refused right away — at start-up, when you
  save it in Settings, and on a manual backup — instead of letting every nightly backup fail
  into the log, which is a failure you discover when you need the backup. The check writes a
  real probe file and removes it again, because /media is readable and only the write
  attempt reveals that the mount is read-only.
• The target must also resolve inside a mount that survives an update (/data or
  /share in the app). A typo like /shre/faceid is writable inside the container but lives
  in the overlay filesystem, so the archive would vanish with the next update — a backup that
  looks like one and is not. Paths are resolved first, so .. segments and symlinks cannot
  step outside. Standalone installs have no such boundary and stay unrestricted.
• A failed backup can no longer cost a good one. The archive is written under a temporary
  name and moved into place only once complete: a write that breaks off (no space, I/O error)
  used to leave a truncated faceid-backup-*.tar.gz behind, which — being the newest — made
  the rotation discard a valid older backup.
• Settings and "Back up now" show the reason when a path is rejected. Saving an unusable path
  previously produced no message at all.
• Fixed: a folder camera suppressed Frigate discovery. With both inputs configured and no
  explicit camera list, only the folder sensor was announced.
• Still open from #33: the app image itself (~1.4 GB) is in every backup because the app is
  built locally. That needs prebuilt images and is tracked separately.
• Fixed: three options were settable and inert. cross_risk_margin, self_outlier_ratio
  and history_keep were offered by the app and read by the service, but run.sh never
  wrote them into the generated config — the same defect as #24, in three more fields. Found
  by a new test that checks every option reaches the generated file.