**Background**: The worklist feature requires a dedicated DB table to store articles associated with invitation lists. This task creates the `ce_worklist_articles` table via an abstract schema change in `db_patches/abstractSchemaChanges`, following the existing CampaignEvents DB patch conventions and generating SQL for each supported DB engine.
====Type of story====
* Backend
====Acceptance criteria====
* The migration creates the `ce_worklist_articles` table with the expected columns used in CampaignEvents: `cewa_id` (PK, auto-increment), `cewa_page_id` (unsigned int), `cewa_page_title` (varbinary(255)), and `cewa_ceil_id` (unsigned bigint).
* The schema follows the existing naming and format conventions in `db_patches/abstractSchemaChanges` and is reflected in generated SQL under `db_patches/mysql`, `db_patches/postgres`, and `db_patches/sqlite`.
* The table is created successfully on a clean MediaWiki install and on update via `update.php`.
* No data is inserted by this migration — schema only.
====Design====
* NOT NEEDED
====Error messages and copy included====
* For happy path: NOT NEEDED
* For unhappy path: NOT NEEDED
====Are there dependencies (on someone else or learning something new)?====
* NOT NEEDED
====Depends on====
* NOT NEEDED
====Testing required?====
* Yes
* Minimum testing to pass QA: The table schema is verified end-to-end by the frontend tasks that exercise the full add/list/delete flow.
* Tested end-to-end in: task-TBD (Worklist tab — add article form) and task-TBD (article list table)
====messages(i18n)====
* NOT NEEDED
====Technical details====
* Use an abstract schema JSON patch in `db_patches/abstractSchemaChanges` as source of truth, then generate DB-specific SQL files (do not hand-edit generated SQL files).
* Keep the table schema aligned with current CampaignEvents conventions for worklist articles (`cewa_*` field naming).
* `cewa_page_title` stores mainspace page title for redlink handling.
* Add index `ce_worklist_articles_ceil_id` on `cewa_ceil_id` for invitation list lookups.
* Ensure `src/Hooks/Handlers/SchemaChangesHandler.php` registers the table creation with `addExtensionUpdateOnVirtualDomain( ..., 'addTable', 'ce_worklist_articles', "$dir/$dbType/patch-add-ce_worklist_articles.sql", ... )` so `update.php` applies it in the CampaignEvents virtual domain.
====Split patches suggestion====
* Branch 1: DB migration file only (schema definition for `ce_worklist_articles`)
====API documentation====
* NOT NEEDED
====Gherkin scenarios====
```gherkin
Feature: Worklist articles DB table schema
Scenario: Table exists with all required columns after migration
Given a MediaWiki instance with the CampaignEvents extension installed
When the DB migration for the worklist articles table is applied
Then the table "ce_worklist_articles" exists in the database
And it has columns: cewa_id, cewa_event_id, cewa_page_id, cewa_page_title
And "cewa_id" is the primary key and auto-increments
And "cewa_page_title" is stored as varbinary with max length 255
Scenario: cewa_event_id references campaign_events.event_id
Given the worklist articles table has been created
Then the "cewa_event_id" column has a foreign key to "campaign_events.event_id"
```