Background: Endpoint to add and/or remove articles in an event's worklist. The worklist is
identified by its page title; the articles to add and remove are grouped by wiki and applied as a
single delta.

Type of story

• Backend

Acceptance criteria

• The endpoint is available only when the Worklist feature flag is enabled (T423606). When disabled, it returns a controlled error response, aligned with the sibling DELETE endpoint (T423656) — i.e. 404, so a disabled wiki does not reveal the resource.
• Only logged in users (not temp account) can use the API
• The endpoint must be documented at: Extension:CampaignEvents/Api (see below)

Messages and copy included

• For happy path: NOT NEEDED (the 204 response has no user-facing message)
• For unhappy path:
  • • Reused (NOT a new key): campaignevents-rest-event-not-found
      • Returned in the API 404 response body when the worklist feature is disabled on the wiki, so a disabled wiki does not reveal the endpoint. Reuses the standard message; do not create a worklist-specific event-not-found message.
  • When using the API to edit a non-worklist page:
    • "campaignevents-worklist-page-not-worklist": "The target page already exists and is not a worklist page.",

Are there dependencies (on someone else or learning something new)?

• Requires investigation of how the extension validates that a page exists on a (possibly remote) wiki. The reviewer hopes this can be done synchronously. Check existing cross-wiki validation patterns in the codebase before implementing.

Depends on

• T423332 (DB layer for the worklist store — addArticle() and isArticleInWorklist())
• T423606 (Worklist feature flag gating must be implemented)
• Behaviour layer updates — an AddWorklistArticleCommand (or equivalent) that performs the permission check and the synchronous article validation, returning a result that distinguishes "added" from "already present". (No dedicated task for this yet — flagged by the reviewer; align with the existing RemoveWorklistArticleCommand shape.)

Testing required?

• Yes
• Minimum testing to pass QA:
  • With feature flag ON: unit tests cover 204 add, 204 remove, 204 no-op (article already present / absent), 400 unrecognised wiki, 400 malformed title, 403 for logged-out or temporary-account users, and 404 (feature disabled).
  • With feature flag OFF: the endpoint is not accessible (404).
• Tested end-to-end in: T423634 (Worklist tab — add article form)

Split patches suggestion

• Branch 1: PATCH handler + route registration + permission check + validation + unit tests.

API documentation

== Add or remove worklist pages ==

Route: `/campaignevents/v0/worklist/{title}/pages`
Content type: `application/json`
Method: PATCH
Returns: 204 No Content

Applies a delta to a worklist's page list: pages to add and/or remove, grouped by wiki. The worklist
is identified by its page title. Only logged-in (named) users may edit. The operation is idempotent:
adding a page that is already present, or removing one that is absent, is a no-op.

=== Parameters ===

`title`
required | path
The worklist page title (e.g. "Event1/Worklist"). The client MUST percent-encode it
(`encodeURIComponent`), including slashes as `%2F` for subpage titles.

`add`
optional | body
Object mapping wiki ID to a list of prefixed page titles to add, e.g. `{ "enwiki": [ "Article One" ] }`.

`remove`
optional | body
Object mapping wiki ID to a list of prefixed page titles to remove, e.g. `{ "enwiki": [ "Article Two" ] }`.

`token`
required | body
CSRF token.

=== Responses ===

204
Success. The delta was applied (or there was nothing to change).

400
The request is invalid: e.g. a malformed title or an unrecognised wiki in the body.

403
The performer is not a logged-in (named) user, i.e. logged out or using a temporary account
(`campaignevents-worklist-edit-permission-denied`).

404
The worklist feature is disabled on this wiki (`campaignevents-rest-event-not-found`).