Trim the readme migration section down to a pointer

Keep the readme simple — state that migration is required from 2.x and
link to the docs, rather than duplicating the full recipe in two places.

* Reduce "Upgrading from 2.x" to a warning and a link
* Shorten the documentation link label to docs.foxelabs.com

Author: joel-james

README.md

@@ -4,7 +4,7 @@ A lite, UI-free Freemius SDK for Foxe Labs WordPress plugins. The library handle
 update delivery, and addon listing by talking to the Freemius API directly. It deliberately ships no admin screens —
 host plugins build their own UI and call into this library for the underlying logic.
 
-📖 **Full documentation:** [docs.foxelabs.com/software/wp-libraries/wp-freemius-client/overview](https://docs.foxelabs.com/software/wp-libraries/wp-freemius-client/overview)
+📖 **Full documentation:** [docs.foxelabs.com](https://docs.foxelabs.com/software/wp-libraries/wp-freemius-client/overview)
 
 ## Requirements
 
@@ -23,47 +23,11 @@ The library autoloads under the `FoxeLabs\Freemius\` namespace via PSR-4.
 ## Upgrading from 2.x
 
 > [!WARNING]
-> **3.0.0 renames the option that stores every license activation, and the library does not migrate it for you.**
-> Skip the migration and there is no error: licenses silently read as inactive, activation UI resets, and premium
-> update delivery stops.
+> 3.0.0 renames the option that stores license activations, and the library does not migrate it for you. Host plugins
+> must migrate the data themselves, or licenses will silently read as inactive.
 
-This release was renamed from `duckdev/freemius-plugin-licensing`, and the stored data moved with it:
-
-| | 2.x | 3.x |
-|---|---|---|
-| Package | `duckdev/freemius-plugin-licensing` | `foxelabs/wp-freemius-client` |
-| Namespace | `DuckDev\Freemius\` | `FoxeLabs\Freemius\` |
-| Activation option | `duckdev_freemius_activation_data` | `foxelabs_freemius_activation_data` |
-
-The library performs no writes of its own — host plugins own the lifecycle — so each plugin must move the option in its
-own upgrade routine. The stored shape did not change, so a straight copy is enough:
-
-```php
-$legacy = get_option( 'duckdev_freemius_activation_data', null );
-
-if ( is_array( $legacy ) && ! empty( $legacy ) ) {
-    $current = get_option( 'foxelabs_freemius_activation_data', null );
-
-    // Never clobber an activation created since the upgrade.
-    if ( ! is_array( $current ) || empty( $current ) ) {
-        update_option( 'foxelabs_freemius_activation_data', $legacy );
-    }
-
-    delete_option( 'duckdev_freemius_activation_data' );
-}
-```
-
-Three things to get right, whatever shape your upgrade routine takes:
-
-* **Run it before the first read** — it must land before anything calls `Freemius::get_instance()` and reads a license.
-* **Don't clobber** — only write the new key when it is empty, or a site that already activated on 3.0 gets rolled back.
-* **Copy, verify, then delete** — use the options API, not a raw `UPDATE wp_options SET option_name`, which bypasses the
-  options cache and any persistent object cache.
-
-The `duckdev_freemius_{plugin_id}_*` transients need no migration — they are 24-hour addon caches that repopulate on the
-next API call.
-
-📖 Full recipe: [Migrating from 2.x](https://docs.foxelabs.com/software/wp-libraries/wp-freemius-client/installation#migrating-from-2-x)
+See [Migrating from 2.x](https://docs.foxelabs.com/software/wp-libraries/wp-freemius-client/installation#migrating-from-2-x)
+for the migration recipe.
 
 ## Architecture