fix(upload): restore configurable batch-size for reverse proxies (#509)

Regression of #208. PR #214 (commit 02a46e0, re-merged at 9b7495e)
shipped the configurable `general_max_upload_batch_size_mb` setting so
users behind Cloudflare Tunnel and other reverse proxies with
per-request size caps could lower the chunked-upload size below their
proxy's limit. Six days later the "Merge main into beta for
release/beta-to-main" commit (28793bb) resolved its conflict by
keeping main's older tree — which silently deleted the migration
(072), the setting input on Settings → General, the i18n strings, the
`useSettingsState` field, and the read in PhotoUpload.tsx, putting the
hardcoded 500MB chunk back. Galleries fronted by Cloudflare have
quietly been broken on batch uploads since then.

Re-applying exactly the same change set:

- `backend/migrations/core/072_add_max_upload_batch_size.js`
  recreated, with a comment pointing at the regression in case the
  same merge accident happens again.
- `frontend/src/components/admin/PhotoUpload.tsx` line 168 now reads
  the setting from query cache and falls back to 95MB (Cloudflare-safe
  headroom under 100MB).
- `useSettingsState.ts`, `GeneralTab.tsx`, `en.json`, `de.json` —
  added the field to the state type + defaults + load path + the
  Site-Configuration input.

Existing installs are safe either way:
- Ran original 072 then lost the file: migrations table still has the
  filename, so the runner skips re-applying. The setting row in
  `app_settings` is also untouched (the deletion was source-only, no
  down migration ran). Now the new code starts reading it again.
- Installed after the regression: migrations runner picks up the new
  072 normally and seeds the setting at 95.

backend/migrations/core/072_add_max_upload_batch_size.js

@@ -0,0 +1,38 @@
+/**
+ * Migration: re-add the configurable upload batch size setting (#509).
+ *
+ * Originally shipped via PR #214 (#208 fix) — users behind Cloudflare
+ * Tunnel and other reverse proxies with per-request size caps need to
+ * bound the chunked-upload size so they don't lose every batch >100MB.
+ * That migration + frontend wiring was lost during a `Merge main into
+ * beta for release/beta-to-main` resolution that picked main's older
+ * tree over beta's, silently deleting the file and reinstating the
+ * hardcoded 500MB chunk in PhotoUpload.tsx.
+ *
+ * Re-introducing the exact same migration here. Idempotent: skips the
+ * insert if the row already exists (e.g. installs that did go through
+ * the original 072 between #214 merge and the main-into-beta merge,
+ * where the migrations-table row was preserved even after the file
+ * was deleted).
+ */
+
+exports.up = async function(knex) {
+  const exists = await knex('app_settings')
+    .where({ setting_key: 'general_max_upload_batch_size_mb' })
+    .first();
+
+  if (!exists) {
+    await knex('app_settings').insert({
+      setting_key: 'general_max_upload_batch_size_mb',
+      setting_value: JSON.stringify(95),
+      setting_type: 'general',
+      updated_at: new Date()
+    });
+  }
+};
+
+exports.down = async function(knex) {
+  await knex('app_settings')
+    .where({ setting_key: 'general_max_upload_batch_size_mb' })
+    .del();
+};