Rename to Nolimit Discounts and move the page under the shared menu

Kristian could not find this plugin in the Nolimit menu, and it still called
itself WooCommerce Email Discount Manager. Both are the display side of the
family rename; neither touches the installed folder.

Plugin Name is now "Nolimit Discounts". The folder, the text domain, the option
prefix and the three tables are deliberately unchanged: WordPress identifies a
plugin as <folder>/<file>, so renaming the folder would not move the
installation on the live shop — it would put a second copy beside it and leave
the old one active. That is a migration with a shim, and it is Kristian's call
rather than a side effect of a label change.

includes/shared-menu.php added, byte-identical to the family copy
(f4862d5c…c63185), and the page moved from the WooCommerce submenu to the
shared parent. The page slug is unchanged, so admin.php?page=… still resolves
and an existing bookmark keeps working — moving a page between parents does not
move its URL.

The label is claimed through the wpmgr_menu_title filter from this plugin's own
bootstrap, NOT by editing the shared file. Which copy of that file a site loads
is decided by activation order, and PHP cannot un-declare a function, so the
first copy wins for the whole request: editing it would make a site with three
of five plugins updated show "Manager" or "Nolimit" depending on who booted
first, and change its mind when a plugin is deactivated. The filter is
idempotent and a plugin still on an older build changes nothing.

The filter is registered before the WooCommerce gate, for the same reason the
updater is: the shared menu's label must not depend on whether this particular
plugin got past a check.

Two assertions, both proven red first. The label is asserted through the filter
rather than by reading the menu, because the menu is only built in an admin
request and the smoke tests run under WP-CLI. And the shared file's sha256 is
asserted, so editing it goes red here rather than going strange on a shop —
appending one comment line produced:

  FAIL  and the shared menu file is the family copy, unedited
        — expected 'f4862d5c…', got '45df6b55…'

Also caught in passing by the kit, working exactly as intended: the new
shared-menu.php was untracked, and "every file the plugin loads is a file the
release contains" failed rather than shipping a zip without it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests/smoke.php

@@ -227,6 +227,29 @@ $request  = new WP_REST_Request( 'GET', '/' . WC_EDM_REST_API::REST_NAMESPACE .
 $response = rest_get_server()->dispatch( $request );
 wc_edm_is( 'and they refuse an unauthenticated caller', 401, $response->get_status() );
 
+/* -------------------------------------------------------------- nolimit -- */
+
+// This plugin claims the shared parent menu's label. Asserted through the
+// filter rather than by reading the menu, because the menu is only built in an
+// admin request and this runs under WP-CLI.
+wc_edm_is(
+	'the shared menu is labelled Nolimit',
+	'Nolimit',
+	apply_filters( 'wpmgr_menu_title', 'Manager' )
+);
+
+// includes/shared-menu.php is byte-identical in all five plugins, and which
+// copy a site loads is decided by activation order. Editing it here would make
+// a site with three of five updated show one label or another depending on who
+// booted first — and PHP cannot un-declare a function, so the first copy wins
+// for the whole request. The hash is the guard: change the file and this goes
+// red rather than the behaviour going strange on somebody's shop.
+wc_edm_is(
+	'and the shared menu file is the family copy, unedited',
+	'f4862d5c3a2d24dadddaaec90c9221d61f2923964e164fd525a800ddcec63185',
+	hash_file( 'sha256', WC_EDM_PLUGIN_DIR . 'includes/shared-menu.php' )
+);
+
 /* ------------------------------------------------------------ woocommerce -- */
 
 $compatible = \Automattic\WooCommerce\Utilities\FeaturesUtil::get_compatible_plugins_for_feature( 'custom_order_tables' );