Message plugin developers without approving or rejecting

[simonhamp]

Adds a way for Marketplace admins to have a conversation with a plugin's developer about a specific plugin, independently of approving or rejecting it.

Admin

• New Message Developer button on the plugin edit page, alongside Approve and Reject. Available for every status.
• View Listing Page promoted out of the ⋮ submenu to sit next to the other header buttons.
• Messages are recorded as plugin activities, so they appear in the existing Activity History relation manager. The note column is wider and wraps so conversations are readable.

Developer

• New Activity tab on the plugin page showing the full history, newest first, with colour coding: green for approvals, red for rejections, purple for messages from NativePHP, sky for the developer's own replies, and muted zinc for everyday status changes.
• The active tab is tracked in the query string (?tab=activity), so refreshing keeps your place.
• A reply box appears above the log — but only for submitted plugins (pending, approved or rejected) and only once an admin has messaged first. Developers can't open arbitrary threads about drafts. This is enforced server-side, not just by hiding the form. Replies are rate limited to 10/min.

Email

• PluginMessageReceived (mail + database) tells the developer a message is waiting and deep-links to the Activity tab. The message body is never included — they have to sign in to read it. A test asserts the rendered email doesn't contain the message text.
• PluginDeveloperReplied notifies support@nativephp.com when a developer replies.

Notes

• No migration — this reuses the existing plugin_activities table with two new PluginActivityType cases, so messages land in the log for free.
• The blade diff looks large but is mostly mechanical: the plugin page's tab group used to be draft-only and is now universal, so the approved and pending/rejected branches moved one level deeper and were reindented. git diff -w shows the substantive change.
• Message bodies render as escaped plain text rather than going through the CommonMark helper the support-ticket thread uses, since that's configured with html_input => 'allow' plus a Blade preprocessor.

Testing

415 plugin-related tests pass, including 32 new ones across PluginMessageDeveloperTest and PluginMessagesTest. Notably test_every_activity_type_renders_with_a_badge_and_icon loops every enum case, which is what proves all the badge colours and Flux icon names resolve.

Not visually verified — the preview webview was erroring throughout, so the timeline layout has only been checked at the render-assertion level.

🤖 Generated with Claude Code