Update DataViews usage to use /wp entrypoint

[aduth]

What?

Updates imports of @wordpress/dataviews to use its /wp entrypoint.

Alternative to #984

Why?

Fixes broken AI settings page when running Gutenberg 23.9.0 or newer.

This is the documented recommendation for using DataViews in plugins built using @wordpress/scripts:

If you're trying to use the DataViews component in a WordPress plugin or theme and you are building your scripts using the @wordpress/scripts package, you need to import the components from @wordpress/dataviews/wp instead of @wordpress/dataviews.

Source: https://github.com/WordPress/gutenberg/tree/trunk/packages/dataviews

The reason this is recommended is also the reason I'm proposing this update now: Since not using the /wp entrypoint causes DataViews to use shared WordPress scripts (instead of bundling those dependencies), DataViews' internal references to APIs could become unreliable if it depends on newer or removed APIs. See also #984

Use of AI Tools

See AI disclosure in #984, though in this pull request I did not use any AI for updating the imports.

Testing Instructions

Repeat Testing Instructions from #984

Screenshots or screencast

Before	After

Changelog Entry

Fixed - Settings page failing to render on Gutenberg 23.9+ after @wordpress/dataviews was removed from the private-apis allowlist.

cc @youknowriad @ntsekouras @oandregal

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.57%. Comparing base (0833eec) to head (890b912).

Additional details and impacted files

@@            Coverage Diff             @@
##             develop     #989   +/-   ##
==========================================
  Coverage      74.57%   74.57%           
  Complexity      3132     3132           
==========================================
  Files            132      132           
  Lines          12213    12213           
==========================================
  Hits            9108     9108           
  Misses          3105     3105           

Flag	Coverage Δ
unit	74.57% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[youknowriad]

Approving but a check from folks working on this project more actively might be good.

[aduth]

There's a remaining lint error on "Path access on WordPress dependencies is not allowed".

ai/eslint.config.mjs

Lines 98 to 103 in 0833eec

	{
	selector:
	'ImportDeclaration[source.value=/^@wordpress\\u002F.+\\u002F/]',
	message:
	'Path access on WordPress dependencies is not allowed.',
	},

This specific restricted syntax may have been inherited originally from Gutenberg and was meant to prevent access to specific files in packages. These days, Gutenberg packages use subpath exports, which strictly prevents (at a Node.js/bundler level) any access to paths not listed in the exports. For this reason, the equivalent rule was removed in Gutenberg in WordPress/gutenberg#72978 and I'd recommend doing the same in this project.

[dkotter]

This specific restricted syntax may have been inherited originally from Gutenberg and was meant to prevent access to specific files in packages. These days, Gutenberg packages use subpath exports, which strictly prevents (at a Node.js/bundler level) any access to paths not listed in the exports. For this reason, the equivalent rule was removed in Gutenberg in WordPress/gutenberg#72978 and I'd recommend doing the same in this project.

Looks like this was originally brought in via #172 and reading through that, seems those rules were pulled from other WordPress repos (I image Gutenberg was definitely an inspiration there). If that rule is no longer valid/needed, I'm fine with us removing that here

[aduth]

Thanks for taking a look @dkotter ! I removed the restricted syntax pattern in 890b912 . For what it's worth, the import in tests/e2e/playwright.config.ts feels like it was a true positive of what the pattern was trying to prevent 😅 Though in the case of the scripts package, (1) I believe this was the intended usage pattern (e.g. there's no documentation for Playwright config, but see similar "Extending the webpack config"), and (2) the @wordpress/scripts package doesn't define exports. I guess I spoke too confidently in my previous comment when I said that "Gutenberg packages use subpath exports" since there are about a half-dozen or so that don't define exports, though those are likely intentional where subpath references like the one that's used in this project are intended.†

† Although my personal opinion is that we should still define those exports even if they're pointing to the exact paths that people are already expecting to be using.