docs(solutions): in-place header edit + APCu cache staleness (Part 3)

Document the trip publish-toggle cache-invalidation finding: an in-place
trip.md `published` edit under cache.check.method: folder + APCu driver stays
stale because the folder checksum is unchanged AND the web APCu store is
unreachable by a CLI clearcache — fixed with apcu_clear_cache() from the web
request. Cross-link the sibling grav-deleteall doc (the create/delete case) as
necessary-but-not-sufficient here, and add the Published/Draft trip status
concept to CONCEPTS.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mpdu3Dt1iVoozHwAMyjrbn

docs/solutions/integration-issues/grav-deleteall-doesnt-invalidate-page-tree-index.md

@@ -99,3 +99,15 @@ config, intentionally not committed as `true`), so both specs **skip loudly**
 with a reason rather than fail misleadingly. They validate whenever the site is
 in travelling mode. This is a known gap in this environment, not a silent hole —
 provisioning `travelling: true` in a dedicated test config would close it.
+
+## Related — Part 3: in-place edits + APCu
+
+The `Cache::invalidateCache()` fix above completes `deleteAll()` for the
+**create/delete** case, because a new or removed child folder advances
+`folderHash` and the `system.yaml` touch bumps `config->checksum()`. It is
+**necessary but not sufficient** for an **in-place frontmatter edit** (e.g. a
+trip publish toggle) under `cache.driver: auto` (APCu): the folder structure is
+unchanged, and APCu lives in web-server shared memory that a CLI `bin/grav
+clearcache` cannot reach. That case additionally requires `apcu_clear_cache()`
+called from the web request. See
+[`grav-in-place-header-edit-apcu-cache-stale.md`](grav-in-place-header-edit-apcu-cache-stale.md).