fix: flush the update cache on every license removal path

[jakejackson1]

Summary

License activation and deactivation already flushed the cached update info, but three paths that change license state did not.

1. Access Pass siblings. maybe_auto_activate_license() / maybe_auto_deactivate_license() called update_license_info() alone. Every add-on covered by the pass kept version info fetched under the old key (so, no package) for up to the 3-hour TTL, plus its stale update_plugins entry.

2. Clearing the key in the settings form. Unlike the Deactivate button, the empty-key branch of maybe_active_licenses() left the cached package in place.

3. The Multisite network cache. delete_version_info_cache() only removes the per-site option, so the gpdf_sl_net_* package a site promoted stayed borrowable via maybe_apply_network_package() for its 3-day TTL — a site that had lost its license could still hand a download URL to the network.

What ends the network entitlement

Withdrawal needs a lost license and ownership of the shared package.

• Lost license means the key was removed or the store rejected it: expired, revoked, disabled, missing, invalid, site_inactive, item_name_mismatch, invalid_item_id, no_activations_left. These all arrive with the key still populated, so the status is the only signal.
• error and rate_limit are deliberately excluded. They are written on a WP_Error, timeout or 429, and treating a failed request as a verdict would strip a package every subsite depends on whenever the licensing server is briefly unreachable.
• Ownership: the promoting blog id is stored alongside the package, so a promotion made by another site — which is therefore still licensed — outlives this site's deactivation.

flush_update_cache() takes no flag; the withdrawal derives from the updater's own key and status, so no caller has to remember to ask for it.

Guards against no-op work

• The sibling flush only fires when the key or status actually moved — a hardcoded GPDF_LICENSE_KEY re-fires the activation action every few hours and would otherwise force a fresh remote request per add-on each cycle.
• The settings-form flush only fires when a key was previously stored — the licensing tab posts an empty field for every registered add-on on an unrelated save.

Testing

16 new tests. Full PHPUnit suite green in both modes: 1149 tests / 3578 assertions single-site, 1149 / 3677 multisite. phpcs clean on the changed files.

The rejection-status tests were verified non-vacuous: with the status gate reverted to the key-only check, all 10 fail.

Follow-up (not in this patch)

All five update_license_info() call sites in src/ are now immediately followed by a flush — that 100% correlation says the invariant belongs inside update_license_info() itself. Deliberately left for 6.17 rather than relocating side effects of a public @since 4.2 method in a hot patch. Same for the settings-clear branch being a second, partial definition of "license removed" alongside delete_license_info().

🤖 Generated with Claude Code