Add meza maint run for ad-hoc maintenance script execution

[Copilot]

Running ad-hoc MediaWiki maintenance scripts required either verbose direct ansible-playbook invocations or writing custom wrapper scripts. The run-maintenance.yml playbook existed but had no CLI entrypoint.

Changes

src/scripts/meza.py

• Adds meza_command_maint_run() — a new maint sub-command routing to the existing run-maintenance.yml playbook
• Supports --wiki <wiki_id> to target a single wiki (default: all wikis) and --args <script_args> to forward arguments to the PHP script
• Unrecognized flags are passed through to ansible-playbook

manual/meza-cmd/maint.md

• Documents the new run directive with usage examples
• Updates the Arguments table and "When to Run Maintenance" section
• Promotes meza maint run as the recommended approach in the "Advanced" section over raw playbook invocations

Usage

# All wikis
sudo meza maint run monolith update

# Single wiki
sudo meza maint run monolith refreshLinks --wiki demo

# With script arguments
sudo meza maint run monolith runJobs --args '--maxjobs=50'

# Combined
sudo meza maint run monolith refreshLinks --wiki demo --args '--verbose'

[Copilot]

@copilot This feature branch was created a week ago from 'dev', and contains a couple commits. I want to work on the branch in my local repo, so I fetched it and checked it out. Over the past week the...

Yes, rebasing the feature branch onto the tip of dev is the right practice here — it replays your commits on top of the latest dev changes, gives you a cleaner linear history, and avoids a merge commit that would otherwise clutter the branch.

After rebasing locally, your local branch and origin will have diverged (different commit SHAs for the same logical changes), so a normal git push will be rejected. The correct way to update origin is a force-push:

# Safest option — fails if someone else pushed to the branch since you last fetched
git push --force-with-lease origin copilot/improve-maintenance-handling

# Unconditional force-push (use only if you're sure no one else is working on the branch)
git push --force origin copilot/improve-maintenance-handling

--force-with-lease is preferred because it acts as a safety check: it refuses to overwrite commits on origin that you haven't seen locally yet, protecting against accidentally clobbering someone else's work.

Full workflow recap:

git fetch origin dev
git rebase origin/dev
# resolve any conflicts, then:
git push --force-with-lease origin copilot/improve-maintenance-handling

Since this is a Copilot-owned branch and the only collaborator is you, --force-with-lease and --force are equivalent here, but --force-with-lease is the habit worth keeping.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud