Provide REST endpoints for all the main Change Request features

Motivation

Change Request can today only be driven through its UI. Its Java API (ChangeRequestManager, the storage manager, the script services) is only reachable from inside the wiki, from Java components or from Velocity/Groovy scripts. There is no HTTP API, so nothing outside the wiki – a shell script, a CI job, an external tool, or an LLM agent – can create or operate a change request.

The consequence is that any automated contribution has to choose between editing pages directly, which bypasses review entirely, and not contributing at all.

Use case: improving the xwiki.org documentation

An LLM agent (or a developer running a script) reviews the documentation, finds outdated or incorrect pages, prepares the fix, and submits it as a change request that a human then reviews and merges. The review step is what makes this safe: the automation proposes, a human approves. The same applies to bulk documentation cleanups, migration scripts, and generally any automation that should go through review rather than write directly to the wiki.

Proposal

Provide REST resources, under the standard XWiki REST API, covering the main Change Request features:

• Listing and discovery: search/list change requests (filtering by status, author, changed page...), and get a single change request with its metadata: title, description, status, authors, reviewers, approvers, changed documents and their file changes.
• Creation: create a change request from one or more document changes – new content, title, objects, attachments, page deletion request, creation from a template – targeting a given wiki/space/page and locale.
• Modification: add a new file change to an existing change request, update its title and description, rebase a file change against the latest published version of the document, split a change request, and delete it.
• Status and merging: move a change request between its statuses (draft, ready for review, ready for merging, closed, and reopening), and merge it.
• Review: add a review (approve or request changes), invalidate/remove a review, list the existing reviews, and list/set the approvers, including delegate approvers.
• Discussions: list and add comments on a change request as a whole and on a specific diff location.
• State and rights introspection: expose whether the current user may edit, review, merge or delete a given change request, and whether it is currently mergeable or in conflict – so that a client knows what it is allowed to do next instead of guessing from a failed call.

Implementation notes

• Follow the XWiki REST conventions (JAXB resources, the /rest/ entry point, Basic auth, HATEOAS links) so that the existing REST tooling and clients work with these resources out of the box. A natural entry point would be something like /rest/wikis/<wiki>/changerequests.
• Rights must be enforced exactly as the UI enforces them. The REST layer must not become a way around the approval rules of the application.
• The resources should be self-describing enough to be usable by an agent without reading the source: stable identifiers, meaningful error responses, and links to the operations that are possible next.