feat(integrations): details modal and Run now for integration logs

[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:

Adds two affordances to the per-integration activity logs view (Audience › Integrations › Logs) to make troubleshooting Action Scheduler retries practical:

• View details — opens a modal showing the full action payload (decoded args, with extended_args preferred when the indexed column was truncated), metadata (action ID, group, scheduled date, attempts, last attempt), and the per-action Action Scheduler log trail.
• Run now — for pending actions only, runs the Action Scheduler action immediately and refreshes the row with the post-run status. Mirrors WooCommerce's default AS admin behavior.

Both REST endpoints sit behind the existing wizard permission gate. The detail endpoint validates that the action belongs to the integration before responding, returning a generic 404 on cross-group access so other-group actions can't be probed through it. Errors thrown by the action's callback during a Run are surfaced as a 200 response with status: 'failed' and the last AS log message — AS itself records the failure and writes the log, so the UI just refetches and shows the result in a snackbar.

Follow-up to #4671 per Miguel's non-blocking review feedback.

Closes DSGNEWS-160.

How to test the changes in this Pull Request:

1. Spin up an isolated env: n env create dsgnews-160 --worktree newspack-plugin:feat/improve-integrations-activity-logs --up && n setup --env dsgnews-160 --yes --woocommerce.
2. Visit Newspack › Audience › Integrations and open the Logs view for an integration that has scheduled actions (Mailchimp, ActiveCampaign, etc.). If you need to generate fixtures, register a reader or trigger a data event so the integration enqueues actions.
3. On a pending row, open the row "…" menu → View details. Verify the modal shows: event label + status badge, action ID, scheduled (GMT), group, attempts, last attempt (or —), pretty-printed args JSON in a <pre> block, and the AS log list.
4. On a pending row, click Run now. Verify a success snackbar appears ("Action completed.") and the row's status flips to Success in place.
5. On a row whose hook callback fails (or temporarily break a callback to force one), click Run now. Verify a failure snackbar shows the AS log message and the row flips to Failed.
6. On any complete, failed, or canceled row, confirm Run now is hidden from the row menu but View details still opens correctly.
7. Force a not-found state: open View details, then rewrite the action_id segment of the request in the devtools network tab and re-issue. The modal should show "This action no longer exists."
8. If you can catch an in-progress action in the list, confirm its status badge renders as "In progress" (no raw-string fallback).

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?

Automated tests were intentionally not added — Action Scheduler is heavy to mock for low value here. Verification is via the manual QA steps above in an isolated env. PHP/JS/SCSS linting and n build all pass.

[Copilot]

Pull request overview

This PR enhances the Audience → Integrations → Logs experience by adding per-action troubleshooting tools: a details modal (full payload + Action Scheduler log trail) and a “Run now” action for pending jobs, backed by new wizard-gated REST endpoints.

Changes:

• Add DataViews row actions for View details (modal) and Run now (POST + refresh + snackbar).
• Introduce shared JS constants/helpers for status labeling (including in-progress) and timestamp formatting.
• Add REST endpoints to fetch per-action detail (including extended args) and to synchronously run pending actions, plus Action Scheduler helper methods to fetch a single action and its logs.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/wizards/audience/views/integrations/style.scss	Adds styling for the new action-details modal layout (meta grid, args pre block, logs list).
src/wizards/audience/views/integrations/logs-view.js	Adds DataViews row actions: details modal + “Run now” trigger with notices and refetch.
src/wizards/audience/views/integrations/log-details-modal.js	New modal component that fetches and renders action payload, metadata, and AS log entries.
src/wizards/audience/views/integrations/constants.js	New shared constants for API base, status map (incl. in-progress), and timestamp formatting.
includes/wizards/audience/class-audience-integrations.php	Registers two new REST routes and implements detail + run handlers with integration ownership checks.
includes/reader-activation/class-integrations.php	Adds action_belongs_to_integration() helper to gate per-integration action access.
includes/class-action-scheduler.php	Adds helper methods to fetch a single AS action and normalized per-action logs.

---

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

[miguelpeixe]

It's looking great!

The "Success" status can be misleading here. The retry action succeeded because it didn't throw an error to AS, but still failed to sync and created a new sync retry action. To avoid confusion, we should change the label to "Completed".

[miguelpeixe]

As discussed internally, it'd be good to have the user email (if available in the action metadata) surfaced as a table column and item in the details.

[chickenn00dle]

@miguelpeixe re: surfacing the user email — done in 2714a32 (with a follow-up fix in ca60d16).

The email is now shown both as a table column in the logs view and as an item in the action details modal. The integration retry actions reference the contact by user_id rather than carrying an email directly, so the backend resolves the current account email from that ID (preferring an explicit email/user_email key when present, and falling back to previous_email for email-change retries when the user can no longer be resolved). The list endpoint primes the user cache with a single cache_users() query so populating the column doesn't fire a query per row. Rows with no resolvable email render as —.