REST API Plugins Endpoint: Plugins are activated before language packages are installed

[orballo]

Problem

When using the REST API endpoint to install a plugin and activate it, the plugin is activated before the plugin's languages are installed. This causes that if the plugin is creating some content during activation (i.e., WooCommerce creates a series of pages), this content is created in English instead of following the language setting from WordPress.

Expected behavior

When installing and activating a plugin via REST API, the content created by the plugin (i.e. WooCommerce) should be created in the same language as WordPress.

Request example

POST /wp/v2/plugins
{
  "slug": "woocommerce",
  "status": "active"
}

Related code

​https://github.com/WordPress/wordpress-develop/blob/b6f639737c5fa722dd5a80f0ad94e48c67c37ffd/src/wp-includes/rest-api/endpoints/class-wp-rest-plugins-controller.php#L364-L402

Possible solution

Invert the order of the operations in the highlighted code so languages are installed first and the plugin is activated after.

https://core.trac.wordpress.org/ticket/62671

## Summary

Expands admin visual regression coverage from 22 to 37 screenshots ahead of the 7.0 admin reskin.

The existing suite had 22 hand-written tests that each repeated the same navigation/screenshot boilerplate and shared a short list of selectors to hide. This replaces that with a data-driven architecture: a single pages array describes every admin screen, and one loop generates all 37 tests. Volatile elements are stabilised in two layers — a global screenshot.css injected at capture time, and per-page Playwright masks for page-specific content.

### Key changes (3 files)

config/screenshot.css (new)
Global stylesheet injected via Playwright's stylePath during screenshot capture. Hides environment-dependent elements — admin bar identity, footer version nag, gravatars, date columns, dashboard widget internals, update timestamps, and live date/time previews — using visibility: hidden to preserve layout. Admin notices use display: none instead because they may or may not exist in the DOM between runs; reserving space for an absent element would shift content and cause false diffs. Block editor modals (welcome guide) are also hidden with display: none since their appearance depends on non-deterministic user preference state.

playwright.config.js
Adds HTML reporter (side-by-side diff images, opens automatically on local runs), full-page capture, 1 % pixel-diff tolerance, CSS animation disabling, and single-worker serialisation in CI to avoid resource contention flakes.

specs/visual-snapshots.test.js
Data-driven test loop over 36 admin pages + 1 unauthenticated login page. Each page entry specifies a section (matching the admin menu), so nested test.describe blocks produce collapsible groups in the HTML report instead of a flat list. Pages that need test content (Edit Post, Edit Page) use setup/teardown lifecycle hooks via the REST API with force-delete cleanup. A waitForPageReady helper waits for network idle, web fonts, jQuery animations, and blurs any focused element to eliminate focus-ring timing diffs. Mask selectors that match zero elements emit a warning so stale masks surface during development rather than silently causing false diffs.

### Pages covered

Section	Pages
Dashboard	Dashboard, Updates
Posts	All Posts, Add New Post, Edit Post, Categories, Tags
Media	Media Library, Add Media
Pages	All Pages, Add New Page, Edit Page
Comments	Comments
Appearance	Themes, Widgets, Menus, Theme File Editor
Plugins	Plugins, Add New Plugin, Plugin File Editor
Users	All Users, Add User, Your Profile
Tools	Available Tools, Import, Export, Export Personal Data, Erase Personal Data, Site Health
Settings	General, Writing, Reading, Discussion, Media, Permalink, Privacy
(unauth)	Login

## Testing

npm run test:visual -- --update-snapshots   # generate baselines
npm run test:visual                         # compare against baselines

Diff images land in artifacts/; an HTML report opens automatically on local runs.

## Trac ticket

https://core.trac.wordpress.org/ticket/62671

## Summary

When client-side media processing handles big image scaling, the client creates a -scaled version and sideloads it back via the REST API. The sideload route's image_size enum was missing scaled, causing 400 validation errors.

This PR:

• Adds 'scaled' to the image_size enum in the sideload route registration
• Adds handling in sideload_item() to record the original file as original_image and update the attachment to point to the scaled version
• Updates the filter_wp_unique_filename() regex to recognize the -scaled suffix, preventing unwanted numeric suffixes

## Test plan

• [ ] Upload a large image (>2560px) with client-side media processing enabled
• [ ] Confirm the scaled sideload request no longer returns a 400 error
• [ ] Verify that other sideload image_sizes (thumbnail, medium, etc.) still work
• [ ] Verify the attachment metadata correctly records original_image and the scaled file dimensions

@westonruter I believe I have addressed all of your feedback. Thanks!