CampaignBars Announcement Manager 0.3.7 — migration from campaign-bars

The Free folder/main file is now:
campaignbars-announcement-manager/campaignbars-announcement-manager.php
The text domain and translation catalog use campaignbars-announcement-manager.
The separate Pro package remains campaign-bars-pro/campaign-bars-pro.php.

Back up the database and existing plugin files before beginning. Verify that the
backup can be restored. This package does not restore backups automatically.

1. While OLD Free is still active, open Campaign Bars > Settings. Turn OFF
   "Delete plugin data on uninstall", save, reload Settings and verify it is off.
   This is essential: old Free 0.3.6 deletes shared campaigns, reports, settings
   and capabilities if its delete-data setting is enabled when WordPress runs
   that old package's uninstall.php. Installing this new package cannot modify
   the old uninstall program.
2. Deactivate Campaign Bars Pro, then deactivate old Campaign Bars Free.
3. Delete the old Free package through Plugins only after confirming step 1.
   Alternatively, move its entire campaign-bars folder outside wp-content/plugins
   through SFTP without invoking WordPress uninstall. Keep that copy with the
   backup. Do not leave an old active or reactivatable copy during migration.
4. Upload CampaignBars Announcement Manager 1.1.2 and the matching Pro 1.1.2.
   Activate the new Free package first, then Pro. Pro's new dependency names the
   new Free slug. An inactive old Free package does not satisfy that dependency.
5. Check existing campaigns, unpublished drafts, history, settings and reports.
   Clear page/CDN caches and verify a published announcement and consent setup.
   Keep delete-data off unless you deliberately want a later uninstall to erase
   the plugin's retained data.

No data is copied to a new namespace. Existing campaignbars_* options, cbars_*
tables/post type, capabilities, cron hook, REST namespace campaign-bars/v1,
admin page campaign-bars, AJAX actions, exports format and browser event names
are retained. Deactivation alone preserves data. Reports and publication history
are not converted into a new format by this package rename.

If both Free packages are marked active, the renamed package defers to legacy
Free regardless of the normal stored loading order and shows an administrator
notice. No other plugin is silently deactivated or deleted. On WordPress 6.9+
standard activation validation also refuses legacy activation while the renamed
runtime is loaded. On WordPress 6.5–6.8 the normal Plugins screen is guarded for
single/bulk activation. Direct programmatic or WP-CLI activation of legacy Free
on those older cores bypasses the screen and is unsupported: remove the old
folder before using automated activation tooling. Do not require/include the
old PHP entry point manually.

When the renamed Free runtime is loaded, its pre-uninstall guard also refuses
legacy removal while delete-data is enabled. It never silently changes that
setting. This guard cannot protect an old standalone installation before the
renamed plugin is active, so step 1 remains essential.

If old Free was already uninstalled with delete-data enabled, activating the new
package cannot recover deleted data. Restore a verified backup through your
normal recovery procedure before continuing.
