Store multiple named HTTP Basic credentials per install

[chubes4]

Summary

• http_basic now stores an account-keyed credential map instead of a single credential
• adds get_account_names() and delete_account()
• credentials configured before this change keep resolving with no migration step

Problem

The provider is documented as generic, and its config field reads "Local auth ref account name, for example logstash" — implying many. It stored exactly one:

if ( (string) ( $config['account'] ?? '' ) !== $account || ... ) {
    return new WP_Error( 'auth_ref_unresolved', ... );
}

save_config() replaced the whole blob, so configuring a second service silently evicted the first. On an install already using http_basic:logstash, adding http_basic:matticspace would have broken Logstash with no error at write time and a confusing auth_ref_unresolved later.

This is the "which credential" axis. It is orthogonal to the principal scoping the base class already provides, which is the "whose credential" axis — both now apply, and a user-scoped config holds its own account set.

Encryption

encrypt_fields() only walks top-level string keys, so nesting credentials under accounts would have written every password to wp_sitemeta in plaintext. Each account entry is therefore encrypted explicitly by the provider on write and decrypted on read. A regression test asserts the plaintext password appears nowhere in the stored option, not merely that the expected key is enveloped.

Compatibility

Installs holding the pre-change flat shape are read as a single-entry map, so existing auth refs resolve untouched and the next save rewrites them into the map. Covered by tests, including adding a new account alongside a legacy one.

Verification

• tests/http-basic-auth-provider-smoke.php — rewritten: coexistence, rotation isolation, deletion, unconfigured lookups, legacy shape, legacy+new coexistence, and no-plaintext-at-rest
• every auth/oauth/proxy smoke in the repo re-run, all passing
• deployed to a live install and confirmed an existing http_basic:logstash credential still resolves against production Logstash after the storage change

AI assistance

OpenAI gpt-5.6-sol via OpenCode found the single-credential limitation while wiring a second Matticspace-backed service, implemented the account map and per-entry encryption, and wrote the regression coverage. Chris Huber directed the work and is responsible for every line.