Add back-photo button; consolidate reset/manage onto one hold-duration button

Back button (new GPIO0, POST /frame/back): the server now tracks a
bounded history of previously-current photos (photo_queue.py), pushed
to on every advance (auto or forced) and popped by back_forced() --
symmetric with advance, so pressing next afterwards returns to right
where you were. frame_client.c's force_advance bool becomes a 3-way
fetch_action_t (NORMAL/ADVANCE/BACK) threaded through the whole fetch
path.

Also folds the separate reset and manage buttons onto one pin
(combo_button.c, replacing reset_button.c/manage_button.c entirely),
disambiguated by hold duration: quick press shows the management menu
(unchanged), ~3s hold-then-release soft-resets (esp_restart(), config
kept -- new), ~15s hold factory-resets (today's old reset behavior,
extended from 10s for clearer tier separation). Driven by a production
board (Seeed XIAO ESP32-C6) exposing only 3 of the ESP32-C6's 8
deep-sleep-wakeup-capable GPIOs -- next/back keep their own dedicated
pins where instant response matters most, everything else shares the
third pin via timing instead of needing its own. Same three-pin layout
now works on both the dev board and the production board.

Fixed a fast-tap bug in combo_button_check() before shipping: it only
did a live gpio_get_level() read to decide whether the button was
pressed at all, so a press fast enough to already be released by the
time boot reached that check was missed entirely (treated as "never
pressed" rather than "quick press"). Added the same latched
esp_sleep_get_gpio_wakeup_status() check the other buttons already use
for exactly this reason.

firmware/main/next_button.c

@@ -17,10 +17,11 @@ static const char *TAG = "next_button";
 
 void next_button_init(void)
 {
-    /* See manage_button.c's manage_button_init() for why this has to run
-     * before gpio_config() -- a deep sleep with this pin armed as a
-     * wakeup source leaves it "held," and nothing un-holds it on wake
-     * except explicitly asking. */
+    /* Every deep sleep with this pin armed as a wakeup source leaves it
+     * "held" (ESP-IDF locks the pin's pull/config across the sleep
+     * transition -- see esp_sleep_gpio_wakeup_prepare_on_hp_periph_powerdown()
+     * in sleep_modes.c) and, confirmed on hardware, never un-holds it on
+     * wake -- the application has to. Must run before gpio_config() below. */
     gpio_hold_dis(NEXT_BUTTON_GPIO);
 
     gpio_config_t io_conf = {
@@ -30,9 +31,12 @@ void next_button_init(void)
     };
     gpio_config(&io_conf);
 
-    /* See reset_button.c for why this API (not ext1) -- it manages the
-     * pull resistor across the sleep transition itself, so the pin
-     * doesn't float and wake the device spuriously. */
+    /* Not esp_sleep_enable_ext1_wakeup_io(): its internal pull resistors
+     * don't hold once the RTC_PERIPH domain powers down for deep sleep, so
+     * the pin floats and reads spuriously low, waking the device instantly
+     * on every sleep entry (confirmed on hardware). This GPIO-wakeup
+     * variant manages the pull resistor itself across the sleep
+     * transition. */
     esp_sleep_enable_gpio_wakeup_on_hp_periph_powerdown(1ULL << NEXT_BUTTON_GPIO, ESP_GPIO_WAKEUP_GPIO_LOW);
 }