Fix: Key Encryption: undecryptable secrets cause a fatal error on every request, and deactivation fails - #1186

Tested 99e22f7 on WordPress 7.2-alpha-63166-src (wordpress-develop trunk 7d64ecfeaf, plus one unrelated KSES change), PHP 8.3.30, with AI Provider for OpenAI active. I enabled Key Encryption, saved a dummy OpenAI key, and then broke decryption by defining WP_SECRETS_KEY (as in the testing instructions).

Before (develop d6b6ad7):

• Every front-end request fatals with Uncaught Secrets_Exception: Cannot decrypt master key. The stack matches the issue: Main::register_provider_data() → has_ai_credentials() → get_option() → Secrets_Bridge::on_read() → Secrets::get(). Core's _wp_connectors_pass_default_keys_to_ai_client() also hits it and shows a "Cannot decrypt master key" notice.
• wp plugin deactivate ai fatals the same way.

After (this PR):

• Front end: HTTP 200 on three consecutive requests, with no fatal and no notice.
• wp plugin deactivate ai succeeds. The encrypted secret is left in place, and after removing WP_SECRETS_KEY and reactivating, get_option( 'connectors_ai_openai_api_key' ) returns the original key again. So the recovery path works end to end.
• Re-saving a key while decryption is broken: the new key is stored in wp_options and used, and the old secret row is removed, as described.
• Key_EncryptionTest: 16 tests pass. With develop's Secrets_Bridge.php swapped in, exactly the 4 new tests error. CI is green, and the branch still merges cleanly into current develop.

I also checked the calls that stay unwrapped. Secrets::delete() in the on_write() fallback and in delete_secret_for_current_filter() ends in Secrets_Provider_Encrypted_Options::delete(), which is just delete_option() and never touches the master key, so it can't throw here. Provider selection only checks is_available() (sodium), so it doesn't decrypt anything either.

A few non-blocking notes, mostly for a follow-up:

1. Plaintext after recovery. After the store works again, a key saved during the outage stays plaintext in wp_options while Key Encryption still reads as enabled. Nothing re-encrypts it until the experiment is toggled or the plugin is reactivated, and the site owner isn't told. The admin notice @hbhalodia suggested on the issue would cover this, and re-running encrypt_all() once the provider's health check passes again could close the gap.
2. Logging. Failures are only logged when WP_DEBUG is on, so on a production site nothing explains why the connector suddenly has no key. That's the same follow-up notice.
3. From reading the code (not reproduced): derive_secrets_key() concatenates LOGGED_IN_KEY . LOGGED_IN_SALT without a defined() check. Catching \Throwable here covers that on the read and write paths, but the provider's health_check() only catches Secrets_Exception, so a site without those constants could still fatal wherever the health check runs. It's a rare setup, so probably follow-up material along with rewording the exception message (both are listed in the issue).

AI disclosure: I used Claude Code to help set up the reproduction and draft this review. I ran and checked every result above myself.