fix: retry license reactivation soon when the store gives no verdict

[jakejackson1]

When a site's URL changes, such as a site cloned to staging, the weekly license check reactivates the key for the new URL. If that reactivation request failed (a timeout, a server error or a rate limit), it was treated like the store refusing the key. The license screen's status was replaced with a generic error, and reactivation was put off for a week. The next weekly check could land just inside that backoff, so a single blip could delay reactivation by up to two weeks.

A failed request is now treated as no answer. Nothing is saved, so the license screen keeps the store's last status and message, and the license check runs again in three hours. If that retry also gets no answer, it falls back to the weekly backoff, so a store that keeps failing isn't retried every few hours. A real refusal (e.g. no activations left) still backs off for a week, as before.

Try it

npm run test:php -- --filter test_licensing_bulk_license_check

The new cases stub the store for the bulk check and the activation request. They cover a successful reactivation, a refusal, a network error and a 429 (each retried, then succeeding), two failures in a row, and the statuses and recorded URLs that are left alone. The no-answer cases fail on hot-patch-6.17.1.

Test plan

• After a URL change, a failed reactivation request leaves the license status and message unchanged and schedules the bulk check about 3 hours out
• A second failed request in a row backs off for a week, with no early retry
• A refusal from the store backs off for a week, as before
• Saving a license on the settings page still shows error / rate_limit when the store can't be reached
• Test_Model_Settings, Test_Addon and Test_Settings pass

More info

Reading the response. Helper_Abstract_Addon::parse_license_response() returns the store's answer, or null when there isn't one: a WP_Error, a non-200 status, or a body with neither license nor error. update_license_status_from_response() now uses it as well, so the rule lives in one place. Its public behaviour is unchanged: a failure is still saved as error, and a 429 as rate_limit, which the settings page and the GPDF_LICENSE_KEY path rely on to show why activation failed.

sync_license_activation_url(). It gets the raw response from a new private request_license_activation(), which activate_license() also uses, and checks it before saving anything. With no answer it saves nothing and fires no gfpdf_addon_post_license_activation, so there's no error overwrite and no update-cache flush. It returns true, meaning "check again soon". The backoff is the existing gfpdf_license_url_change_{slug} transient, which now holds a state: retry (1 day) after the first no-answer, and blocked (1 week) after a refusal or a second no-answer. Only blocked stops an attempt, and a successful activation clears the state.

Retry scheduling. Model_Settings::licensing_bulk_license_check() schedules the retry when sync_license_activation_url() returns true. It and the bulk check's two existing "+3 hour" retries now share schedule_bulk_license_check_retry(), which keeps a retry that's already due sooner. The deprecated per-add-on schedule_license_check() ignores the return value. Nothing schedules its cron hook any more, and Controller_Upgrade_Routines clears leftover events.

Cleanup. activate_license_with_backoff() had one caller left, maybe_activate_hardcoded_license(), so it is inlined there with its 3-hour backoff unchanged.

Not in this PR. maybe_activate_hardcoded_license() still saves error over the stored status when the store can't be reached. It retries on the next admin request after 3 hours, so it recovers on its own. It's a separate change if wanted.

Manual test. On a dev site, the key was deactivated for the site's URL with the real store and a different URL recorded, so the real bulk check returned site_inactive. Success reactivated for real. A simulated timeout or 429 on the activation kept the real site_inactive status and message and scheduled the 3-hour retry, which then reactivated for real. Two failures in a row, and a simulated no_activations_left, each backed off for a week with no attempt on the next check.

Tests. Eleven cases in Test_Model_Settings, all run through the bulk check that drives reactivation in practice. Test_Model_Settings, Test_Addon, Test_Settings, Test_EDD_SL_Plugin_Updater and Test_Model_Install pass locally (167, 38 multisite skips), and PHPCS is clean. A live bulk check against the real store on a dev site left three licensed add-ons valid.