Fix build + HTTP + mDNS so the firmware actually serves out of the box

[pmokbel]

Three small fixes that get the published source building and serving HTTP correctly out of the box. Each fix is its own commit with a detailed message; this PR is intended to be safe to merge as-is with no behavioral change beyond "the device works."

1. Enable TinyUSB suspend/resume Kconfigs (bf7d6ff)

main/hal/storage/hal_storage.cpp:151,156 uses TINYUSB_EVENT_SUSPENDED and TINYUSB_EVENT_RESUMED unconditionally. In espressif/esp_tinyusb >= 2.x those enum values are gated behind CONFIG_TINYUSB_SUSPEND_CALLBACK / CONFIG_TINYUSB_RESUME_CALLBACK. dependencies.lock doesn't pin esp_tinyusb, so the component manager resolves the latest and a fresh idf.py build from a clean clone fails with:

error: 'TINYUSB_EVENT_SUSPENDED' was not declared in this scope
error: 'TINYUSB_EVENT_RESUMED'   was not declared in this scope

Fix: enable both Kconfigs in sdkconfig.defaults.

2. Bump LWIP_MAX_SOCKETS so httpd_start can bind (e87a2cb)

apps/app_server/app_server.cpp:1418 sets hc.max_open_sockets = 13. ESP-IDF's httpd_start() validates this against LWIP_MAX_SOCKETS - 3 (three sockets reserved internally). The IDF default LWIP_MAX_SOCKETS=10 leaves only 7 available, so httpd_start() returns ESP_ERR_INVALID_ARG:

E (...) httpd: Config option max_open_sockets is too large
        (max allowed 7, 3 sockets used by HTTP server internally)
        Either decrease this or configure LWIP_MAX_SOCKETS to a larger value
E (...) app_server: httpd start fail

The HTTP server then never binds port 80. Devices flashed from a clean build of this repo accept Wi-Fi associations and DHCP, but nothing answers on 192.168.4.1 — captive portal and LAN UI are both unreachable. The error logs to UART (GPIO 5/4 per the current console config), so the symptom is invisible to anyone debugging over USB-CDC.

Fix: set CONFIG_LWIP_MAX_SOCKETS=16 so the configured 13 + 3 internal fits.

3. Initialize mDNS at boot instead of on first AP client (f61f77e)

mdns_init() / mdns_hostname_set() / mdns_instance_name_set() lived inside the WiFiEvent::AP_STA_CONNECTED event handler — i.e. mDNS was only initialized when a phone joined the device's softAP.

Consequences:

• In STA-only operation (or any boot where no station ever joins the softAP), mDNS is never initialized and <device_name>.local doesn't resolve on the LAN.
• The behavior is timing-dependent: as soon as any phone briefly joins the AP, mDNS starts working retroactively for STA too. This makes the bug intermittent and easy to miss in testing.

Fix: move the init to app_server_init, right after URI handlers are registered. The mdns component watches netif up/down events itself, so one init at boot covers both STA and AP cleanly. The existing rename path in h_wifi_config already re-calls mdns_hostname_set() so renaming still works.

Also adds an _http._tcp service advertisement so the device shows up in Finder's Network sidebar and dns-sd -B _http._tcp without needing to know the hostname.

The event handler is reduced to just logging the transition.

---

Test plan

Built clean against ESP-IDF v5.5.1 with idf.py build. Before the LWIP fix: httpd start fail at boot. After: papercolor server ready, 18 routes and http://192.168.4.1/ serves the captive portal. After the mDNS fix: papercolor.local resolves on STA without needing a phone to ever associate to the AP.

No behavioral change beyond "the documented behavior actually happens."