First-time admins have no on-screen path to discover Desktop Mode

[epeicher]

Summary

After installing and activating the plugin, a fresh admin sees nothing in the WordPress UI: no admin notice, no dashboard widget, no admin-bar entry. The only entry point is the /desktop-mode/ portal URL, which the user has to either already know or read in the plugin docs.

The admin-bar entry that would be the discovery affordance is gated on the very thing it's supposed to enable — classic chicken-and-egg.

Evidence

• No admin_notices, wp_dashboard_setup, or wp_add_dashboard_widget callbacks anywhere in the codebase.
• add_action( 'admin_bar_menu', 'desktop_mode_admin_bar_toggle', 190 ) registers the toggle at includes/admin-bar.php:279.
• desktop_mode_admin_bar_toggle() early-returns at line 38 unless desktop_mode_is_enabled() is true.
• desktop_mode_is_enabled() (includes/helpers.php:17-23) reads user meta desktop_mode_mode, which is unset by default → admin-bar entry is hidden.
• The only entry point is the /desktop-mode/ portal — includes/portal.php:25, 96, 108-119.

Impact

First-time UX: a fresh admin enables the plugin and sees no change to their admin. Adoption suffers and the plugin appears broken. Confirmed in both automated test runs.

Suggested fix

Pick one (or both):

1. Render the admin-bar entry unconditionally for users who hold the relevant capability. When desktop mode is off, show "Switch to Desktop Mode" (the label is already in place at includes/admin-bar.php:39-41). This is the lowest-cost fix.
2. One-time admin notice on activation, dismissible, pointing to /desktop-mode/. Use the plugin's activation hook to set a transient and admin_notices to render.

A dashboard widget is also an option but probably overkill given (1).

Severity

Medium. UX/discovery only — feature still works for users who know the URL — but it materially affects first impressions and adoption.