Content patches: Groovy authoring ergonomics — autocomplete and the static-import spike (P3)

[romain-pm]

Sub-issue of #725 (P3, remainder). The Groovy bridge itself shipped with #697: the operations engine is exported (org.jahia.modules.javascript.modules.engine.contentpatches), reachable via the ContentPatchService OSGi service, with runnable samples (tests/cypress/fixtures/groovy/contentPatchParityOperations.groovy), a guide section, and operation-by-operation parity asserted by contentPatchGroovyParityTest.cy.ts. What remains is the authoring ergonomics for Groovy and Java developers.

Scope

• Static-import spike (open question 3 of Content patches: Java-first framework with Groovy and TypeScript bridges #725): determine whether a META-INF/patches Groovy script (executed by core's GroovyPatcher via ScriptEngineUtils) can statically import the exported API, or whether the dynamic BundleUtils.getOsgiService("…ContentPatchService", null) lookup is the only supported pattern. Document the verdict in the guide either way — the dynamic pattern stays the documented baseline.
• IDE autocomplete story: document the provided-scope Maven dependency (javascript-modules-engine-java) that gives a Java module's IDE completion on ContentPatchOperations and its option keys while runtime access stays dynamic; decide whether a GDSL file for IntelliJ adds enough value for patch scripts.
• Javadoc as contract: the exported package's javadoc documents every option key with its default — make it the referenced option-key contract (it is the autocomplete surface for map-based calls from Groovy).

Dependencies

• Blocked by feat: content patches — run-once content transformations in JavaScript #697 (the exported API must be merged and released).
• Independent of the tooling work (P4).
• Feeds the entry criteria of the core-adoption proposal (P6): ergonomics are part of the API shakeout.