Suggest plugin categories with Jev and allow more than one per plugin

[simonhamp]

Plugins can now be in more than one marketplace category, and Jev suggests which ones they belong in. Admins apply the suggestions with one button on the plugin's edit page.

Until now each plugin had a single category, filled in by the keyword backfill command. This adds a categories JSON column. The migration copies each plugin's current category into it, and the directory filter and the backfill command now use it.

How the suggestions work:

• SuggestPluginCategories gives Jev the plugin's title, description and the first 5,000 characters of its README as plain text. The rest of a README is mostly install steps and API reference.
• Jev gets one yes/no question per category. A single choice question would spread its confidence across the categories, so a plugin that fits two of them could fall below the threshold on both.
• Categories Jev is at least 50% sure of are kept, likeliest first, up to three. They're stored in category_suggestions. Nothing is applied automatically.
• Jev is asked when a plugin is created (after the GitHub sync fills in its details) and again when it's submitted for review, so the reviewer sees suggestions based on the latest README.

In the admin, the plugin edit page has a new Categories section with a checkbox per category, Jev's picks with percentages, an "Ask Jev" button and an "Apply suggestions" button. Applying sets the plugin's categories to exactly Jev's picks. The button only shows when that would change something.

For the plugins we already have, php artisan plugins:auto-categorise asks Jev about each one and applies its picks. Plugins Jev isn't sure about keep the category they have and are listed at the end. It skips plugins Jev has already been asked about, so a run that fails part way can simply be run again, and a real run after --dry-run doesn't ask Jev twice.

Things to watch:

• The old category column is still there. Nothing reads it any more, but dropping it in the same migration would break any checkout sharing a local database that hasn't pulled this yet. It can go in a follow-up.
• tests/TestCase.php now fakes Jev for every test. Creating or submitting a plugin queues a Jev request, tests run the queue synchronously, and a TYPESAFE_API_KEY in .env would otherwise make paid calls from the suite.
• Filament's refreshFormData() does nothing for array fields, because it dot-flattens the record first. The Apply action sets the checkboxes with $set instead, and a test saves the form after applying to catch a regression.
• Production needs TYPESAFE_API_KEY. Without it, Ask Jev shows an error and the queued requests fail.
• plugins:backfill-categories (the keyword version) still works, but it isn't needed once the new command has run.

After deploying: run the migration, then php artisan plugins:auto-categorise --dry-run, check the table, then run it without --dry-run.

Testing: new tests cover the job, the admin section, the command, the migration, the directory filter and plugin creation. This also fixes two tests in CustomerPluginReviewChecksTest that have failed on main since #534 made a demo video required. They create their plugin without one, so submitting stopped early. They now add an attested demo video first. Those were the only failures in the full suite. I haven't tried the admin page in a browser or run the command against real data.

🤖 Generated with Claude Code