fix(add-page-by-form): patch Grav-2.0 edit-mode header fatal + deploy wiring

Adding a new photo while editing an entry 500s: add-page-by-form's edit branch
reads existing frontmatter via `(array)$page->header()`, but Grav 2.0's
Grav\Common\Page\Header keeps data in a protected `items`, so the cast mangles
keys and `$original_frontmatter['photos']` is never set → array_merge(null,…)
TypeError. Fix: use Header::toArray() (clean keys, stdClass fallback) + guard the
per-field merge. Grav 2.0.7 does not change this — only the plugin fix does.

add-page-by-form is abandoned upstream (last release 2023-09) and its dir is
git-ignored/GPM-managed, so the fix is tracked as deploy/patches/*.patch and
re-applied after any GPM install/update:
- make apply-plugin-patches (local) — chained into install-plugins
- make remote-apply-plugin-patches-{test,prod} — piped over SSH into
  `patch -p1 --forward`; chained into remote-install-plugins / remote-update-plugins
Content syncs don't touch user/plugins/, so the patch survives them; only a GPM
op wipes it (now auto-restored). Runbook + README document the step and a
verify check. Remove once the plugin is forked.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

deploy/patches/README.md

@@ -0,0 +1,51 @@
+# Local plugin patches
+
+Patches for **third-party, GPM-managed plugins** that live under
+`user/plugins/` — which is **git-ignored** (see `user/.gitignore`), so these
+edits do **not** travel with the content repo and are **overwritten by
+`make install-plugins`** / a fresh image build. Keep the fix here (tracked) and
+re-apply it after any plugin (re)install, until the plugin is forked upstream.
+
+### Local (dev)
+
+```sh
+make apply-plugin-patches            # git apply, idempotent (skips if applied)
+```
+
+`make install-plugins` runs this automatically as its last step.
+
+### Remote (test / prod)
+
+```sh
+make remote-apply-plugin-patches-test
+make remote-apply-plugin-patches-prod
+```
+
+Each patch is piped over SSH into `patch -p1 --forward` at the webroot (no scp),
+so it is a no-op when already applied. **Runs automatically** as the last step of
+`remote-install-plugins-*` and `remote-update-plugins-*` — GPM lays down pristine
+plugins, so the patch must follow every GPM install/update. Content pulls
+(git-sync / `remote-fetch-content`) do **not** touch `user/plugins/`, so the patch
+survives ordinary content syncs. Requires the `patch` tool on the server.
+
+Verify a patch is live on a server:
+`grep -c toArray user/plugins/add-page-by-form/add-page-by-form.php` (≥1 = applied).
+
+## add-page-by-form-grav2-header.patch
+
+Fixes a fatal when **adding a new photo while editing an entry** (front-end
+journal edit, milestone M2 / R9).
+
+- **Plugin:** `add-page-by-form` 3.3.0 (abandoned upstream — last release Sept 2023).
+- **Bug:** the edit-mode branch reads existing frontmatter with
+  `(array)$pages->get($folder)->header()`. On Grav 2.0 `header()` returns a
+  `Grav\Common\Page\Header` object whose data sits in a **protected** `items`
+  property, so the `(array)` cast produces mangled keys (`\0*\0items`) and
+  `$original_frontmatter['photos']` is never set → `array_merge(null, …)`
+  throws a `TypeError` (PHP 8) on any edit that uploads a new file.
+- **Fix:** use `Header::toArray()` (clean keys) with a fallback to the cast for
+  classic stdClass headers, and guard the per-field merge against a
+  missing/non-array original.
+
+Remove this patch once `add-page-by-form` is forked and the fix lands in the
+fork (then pin the fork instead of the GPM package).