Premium Analytics: add forced Loading/Error/Empty Storybook stories for migrated widgets

[chihsuan]

Proposed changes

Why: The WidgetState migration (#50383) converts the dashboard widgets to render their own loading / error / empty states via <WidgetState>, but there was no way to review those states directly in Storybook — the stories only exercised the populated (ready) state. Reviewers and designers need to see each widget's loading, error, and empty state without a live backend. These stories were split out of #50383 to keep that PR focused on the behavior change.

How: Each migrated widget gains Loading / Error / Empty stories that force the state through the mock layer rather than rendering the populated fixture:

• The state is forced in beforeEach via setReportMockState( '<endpoint>', 'loading' | 'error' | 'empty' ) and cleared in the returned cleanup, so it never leaks into sibling stories.
• Each forced-state story renders on a date preset (or row quantity) distinct from the widget's other stories, giving it its own query-cache entry so it hits the mock fresh instead of reading another story's cached success from the shared query client.
• Forced-state stories are tagged !autodocs — the mock override is keyed by path, so leaving them on the shared autodocs page would drag the sibling stories into the same state.
• New widgets/stories/force-stats-mock-state.ts forces states for the Stats endpoints that setReportMockState can't reach because a later-registered analytics-proxy handler shadows them.

What:

• 50 widget story files gain forced Loading / Error / Empty stories.
• New widgets/stories/force-stats-mock-state.ts helper for endpoints the default mock router shadows.

Note: the emails and top-posts forced-state stories ship in #50383, not here — their pre-existing stories passed isLoading / isError props that the migration removed from the leaderboard components, so rewriting them is coupled to that PR and required to keep it green.

Stacked on #50383; base will retarget to trunk automatically once that merges.

Testing instructions

• Build the dashboard/Storybook and open Packages → Premium Analytics → Widgets.
• For a migrated widget (e.g. Search terms, Store performance, Subscriber highlights), open its Loading, Error, and Empty stories and confirm each renders the corresponding <WidgetState> state (error shows a Retry action; empty shows the neutral glyph + copy).
• Confirm the widget's Default / WithComparison / dashboard stories still render populated (the forced state doesn't leak across stories).

[jp-launch-control]

Code Coverage Summary

No summary data is available for parent commit bf45c78, so cannot calculate coverage changes. 😴

If that commit is a feature branch rather than a trunk commit, this is expected. Otherwise, this should be updated once coverage for bf45c78 is available.

Full summary · PHP report

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• 🔴 Specify whether this PR includes any changes to data or privacy.
  
• 🔴 Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so:

## Does this pull request change what data or activity we track or use?

My PR adds *x* and *y*.

---

🔴 Action required: Please add missing changelog entries for the following projects: projects/packages/premium-analytics

Use the Jetpack CLI tool to generate changelog entries by running the following command: jetpack changelog add.
Alternatively, you can check the "Generate changelog entries" checkbox in the PR description to have them auto-generated.
Guidelines: /docs/writing-a-good-changelog-entry.md

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!