Fix config read-modify-write race and two firmware buffer edge cases

Found by a thorough code review:

- server/app/config.py's load()/save() each locked only their own file
  I/O, not the full read-modify-write cycle each route does around
  them. Since uvicorn dispatches sync routes to a thread pool, two
  concurrent requests (e.g. the device's own poll landing alongside a
  web UI edit) could each load() the same on-disk state and the
  second's save() silently clobber the first's changes. Added
  config.locked() (backed by an RLock, since load()/save() also take
  the lock internally) and wrapped every mutating route's
  load/mutate/save span in it -- kept outside the lock wherever a route
  also does slow Immich network I/O, re-loading fresh state right
  before the actual mutation instead. Verified with a new concurrency
  stress test (many concurrent /api/queue/promote and /api/config
  calls) alongside the existing scratch suite.
- firmware/main/root.html's SSID/password/toolsserver/access-token
  inputs had no maxlength, so pasting something longer than the
  matching NVS buffer (wifi_provisioning.h's FRAME_CFG_*_MAX_LEN) was
  silently truncated with no indication why the device later can't
  connect or gets 401s.
- frame_client.c's share_url buffer (256 bytes) could be too small in
  the worst case -- toolsserver (128) + "/frame/share/" + asset_id (47)
  + "?token=" + access_token (64) can reach ~266 bytes, silently
  dropping the token off a request that would then just 401 with no
  obvious cause. Widened to 320.

firmware/main/frame_client.c

@@ -608,7 +608,14 @@ static esp_err_t show_menu_level(const frame_config_t *cfg, fetch_action_t actio
     char location_line1[32];
     char location_line2[32];
     char taken_at[32];
-    char share_url[256];
+    /* Wider than the other URL buffers in this file: unlike a fixed path,
+     * this one stacks toolsserver (up to 128) + "/frame/share/" + an
+     * asset_id (up to 47) + "?token=" + an access_token (up to 64) --
+     * worst case ~266 bytes, which a 256-byte buffer could silently
+     * truncate the token off of (build_url()'s bounds check avoids an
+     * overflow, but a truncated/dropped token still means the resulting
+     * request just 401s with no obvious cause). */
+    char share_url[320];
     fetch_photo_info(cfg, location_line1, sizeof(location_line1), location_line2,
                       sizeof(location_line2), taken_at, sizeof(taken_at), share_url, sizeof(share_url));