[Update Workflow] Phase 5: GUI-driven update UX

[darksidemilk]

Summary

Part of a 6-phase roadmap (see #1005 for Phase 1 and the full roadmap list).
Adds channel selection and a one-click update to the FOG Configuration page,
backed by Phase 1's updatefog.sh. Depends on Phase 1 (#1005) for the
channel/branch map, fog_git_path, and fogupdate.log.

Design

• Channel selector + status, added to
  packages/web/lib/pages/fogconfigurationpage.page.php's version() method
  (~line 132) and its companion
  packages/web/management/js/fog/about/fog.about.home.js: a <select>
  bound to the FOG_UPDATE_CHANNEL setting mirrored by Phase 1, saved via
  this page's existing settings-save AJAX pattern.
• Update-available check: new endpoint (sibling to the existing
  packages/web/status/mainversion.php, e.g. status/checkupdate.php) that
  runs git ls-remote/git fetch --dry-run against $fog_git_path for the
  selected channel's branch and compares to local git rev-parse HEAD. This
  is stricter than mainversion.php's phone-home (which only compares
  FOG_VERSION strings and can't answer "newer commit" for dev/beta
  channels). Channel value is validated against the fixed 3-item map before
  any shell invocation -- never raw user input reaching the shell.
• Update button -> SSH-triggered updatefog.sh: "Update Now" opens an
  SSH connection to localhost as root, using a dedicated keypair
  generated once during install and installed into root's
  authorized_keys with a command="..." forced-command restriction
  limiting it to running updatefog.sh only (never a general root shell from
  the web tier). Launches updatefog.sh --channel <selected> -y fully
  detached (nohup setsid ... >>fogupdate.log 2>&1 & disown) and returns
  immediately.
  • Why SSH, not a direct PHP exec(): updatefog.sh restarts
    Apache/PHP-FPM as part of installfog.sh. A child process of PHP-FPM
    would be killed mid-run when its own parent service restarts. SSH spawns
    an independent, detached process that survives the restart.
• Progress/wait screen: on click, show a modal: "Update running -- this
  can take several minutes. This page will stop responding while services
  restart; refresh once it's done." No live polling in this first pass --
  the config page's normal load already re-checks version/update status.
• Failure/auto-revert visibility: on page load, tail the last N lines of
  $servicelogs/fogupdate.log (Phase 1) into a collapsible "Last update log"
  panel, so an admin who refreshes after a failed+auto-reverted update sees
  why without needing SSH access themselves.

Files touched

• packages/web/lib/pages/fogconfigurationpage.page.php
• packages/web/management/js/fog/about/fog.about.home.js
• New packages/web/status/checkupdate.php
• New packages/web/status/triggerupdate.php (or router-based API action --
  match whichever pattern mainversion.php's siblings already use)
• lib/common/functions.sh (install-time SSH keypair + forced-command
  authorized_keys setup, called once during installfog.sh)

Verification

• From the GUI, select each channel and confirm the update-available
  indicator matches git ls-remote truth for that branch.
• Click "Update Now" on a channel with a real pending update; confirm the
  modal appears, the SSH-triggered updatefog.sh completes (verify via
  fogupdate.log), and a page refresh shows the new version/log panel.
• Confirm the forced-command SSH key cannot run anything other than
  updatefog.sh (attempt an arbitrary command over that key and confirm
  it's rejected).