Content patches: core adoption proposal — move the framework next to Patcher (P6)

[romain-pm]

Sub-issue of #725 (P6). The engine-hosted phase (#697) is explicitly interim: the natural home of the operations engine is Jahia core, next to Patcher/BundleInfoJcrHelper, so that a pure-Java module no longer depends on the JavaScript engine bundle to write content patches.

Scope

• Entry criteria check: the exported API has survived real use — Groovy ergonomics settled (P3), tooling consuming it (P4), no pending breaking changes. The API was built core-ready by construction: no GraalVM or engine-internal types in its signatures (manifest uses:="javax.jcr,org.jahia.services.content,org.slf4j").
• ADR + core ticket: propose the move — package rename to a core namespace, ContentPatchService registered from core — with the migration story for early adopters: the engine keeps a deprecated delegating façade for one release cycle.
• Core niceties unlocked by the move: inject the operations as a GroovyPatcher binding so Groovy patch scripts get zero-lookup access; evaluate unifying the two run-once lifecycles (jahiamodule-extender for Groovy, engine registrar for JS) behind one core framework.

Dependencies

• Blocked by the Groovy-ergonomics work (P3) and the tooling work (P4) — together they are the API shakeout that must precede freezing the surface under core's compatibility rules.
• The CND-comprehension work (P5) informs the core proposal but does not block it.