Support a custom first-boot script (editable in Reflash's UI)

[eliasbakken]

Problem

There's currently no way to customize a freshly-flashed Rebuild image beyond what Reflash's fixed settings (WiFi, SSH, screen rotation) cover. Users who want to install extra Klipper plugins (e.g. led_effect) or drop in their own printer config files have to do it by hand over SSH after every reflash.

Proposed feature

Add a text editor to Reflash's web UI where the user can write an arbitrary bash script. Reflash saves the content to a file (transferred to the eMMC the same way rebuild-settings already is, as the final step of install). On the fresh Rebuild image's first boot, a service (likely rebuild-first-run, or a sibling service) runs this script as-is, once.

The script content is entirely up to the user - typically it'll install one or more Klipper plugins (clone + symlink into klippy/extras/, add a Moonraker update_manager entry) and/or overwrite their own printer.cfg and included config files via heredocs (cat <<'EOF' > printer.cfg, quoted delimiter so Jinja/gcode syntax passes through literally with no escaping needed).

Prior art / validation

• A standalone version of the plugin-install part was written and tested on real hardware: install-led_effect.sh in Rebuild's (gitignored) user_scripts/ folder. It clones klipper-led_effect, symlinks it into klippy/extras/, adds the Moonraker update_manager section, and restarts klipper/moonraker - idempotent, and written to run as root (matching how rebuild-first-run actually executes).
• Note: it does the file operations (git clone, symlink, config edit) as the printer user via sudo -u printer, and the service restarts as root directly - printer deliberately has no passwordless sudo on Recore, so it can't reuse upstream install scripts that shell out to sudo systemctl themselves.

Open questions

• Where does the script live on the fresh image, and what runs it - a new dedicated systemd service, or an addition to rebuild-first-run?
• Should there be any safety rail (confirmation step, dry-run/preview, size limit) given this executes arbitrary root-context bash from a web text field, or is that an accepted tradeoff given the target audience (Recore's own maintainer/owner)?
• Not targeted for v1.1.0 - first release should ship without this.