feat(integrations): add inactive plugin state

[chickenn00dle]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Surfaces the install/active status of an integration's required plugins on the Audience → Integrations screen so admins can resolve missing dependencies without leaving the page.

• Adds Integration::get_required_plugins() so integrations can declare the plugins they depend on. The base implementation returns an empty array; ESP overrides it to report newspack-newsletters install/active state via Plugin_Manager::get_managed_plugin_status().
• Exposes the new required_plugins payload on each integration in the wizard REST response.
• Updates the integrations card UI so that, when a required plugin is installed but inactive, the primary action becomes "Activate" and triggers a POST /newspack/v1/plugins/{slug}/activate call followed by a refetch. When a required plugin is not installed at all, the card renders a "Requires …" requirements affordance instead.

How to test the changes in this Pull Request:

1. Check out the branch, build the plugin (n build newspack-plugin), and load Newspack → Audience → Integrations in the admin.
2. With Newspack Newsletters active: confirm the ESP integration card behaves as before (Enable / Connect / Configure actions, no requirements text).
3. Deactivate Newspack Newsletters (keep it installed): reload the page and confirm the ESP card now shows an Activate button. Click it and confirm the plugin activates, the page state refreshes, and the card returns to its normal Enable/Connect state.
4. Uninstall Newspack Newsletters entirely (or rename its directory): reload the page and confirm the ESP card shows a "Requires Newspack Newsletters" requirements label and no Activate action is offered.
5. Verify the REST response feeding the screen includes a required_plugins array for the ESP integration with slug, name, is_active, and is_installed keys.
6. Sanity-check other integrations (without overrides) still load with an empty required_plugins array and unchanged UI.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[Copilot]

Pull request overview

Surfaces required plugin status for Audience integrations so admins can see missing/inactive dependencies and activate installed dependencies from the Integrations screen.

Changes:

• Adds a required_plugins integration API contract and includes it in integration settings responses.
• Declares Newspack Newsletters as the ESP integration dependency.
• Updates the integrations card UI to show requirements or an Activate action based on dependency status.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/wizards/audience/views/integrations/settings-section.js	Renders plugin requirement labels and Activate actions on integration cards.
src/wizards/audience/views/integrations/index.js	Adds plugin activation API handler and refetches settings after activation.
includes/reader-activation/integrations/class-integration.php	Adds base get_required_plugins() method.
includes/reader-activation/integrations/class-esp.php	Reports Newspack Newsletters install/active status for ESP.
includes/reader-activation/class-integrations.php	Exposes required_plugins in the integrations settings payload.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[miguelpeixe]

We should have an in-flight guard, loading state, and .catch() here.

[miguelpeixe]

Non-blocking: Plugin_Manager::get_managed_plugin_status() re-runs on every wizard REST hit.

get_plugins() is cached intra-request, but wp_get_themes() inside get_installed_plugins() re-scans /themes. Two integrations declaring the same required plugin = two scans. Not on a hot path (admin-only), but worth memoising as a static map keyed by slug before more integrations land.

[miguelpeixe]

Non-blocking: activatablePlugin = missingPlugins[ 0 ] picks only the first inactive plugin; after clicking Activate the card just re-renders with the second one.

Today's ESP has a single required plugin, so this is latent, but the framework is clearly designed for multi-plugin. Either chain activations or restructure to requiresInstall = missingPlugins.filter(!is_installed) and activatable = missingPlugins.filter(is_installed).