Stale account ID cache after changing API credentials in settings form
When an administrator updates the Conductor API credentials (e.g. rotates an API key, switches to a Bearer token, or changes to a different Conductor account) via `/admin/config/services/conductor`, the previously resolved Conductor account ID remains cached. All subsequent API calls — draft creation, draft listing, deletion — continue using the stale account ID until the cache naturally expires.
This can silently cause:
* API requests hitting the wrong Conductor account when credentials are switched between accounts
* Draft operations failing with unexpected errors if the old account ID is no longer valid under the new credentials
**Root Cause:**
getAccountId() caches the resolved Conductor account ID using the tag `conductor_api:account_id`:
```
$this->cache->set($cid, $accounts[0]['accountId'], tags: [
'conductor_api:account_id', // ← shared tag across all users
'user:' . $this->currentUser->id(),
]);
```
Without invalidation, changing the configured key — whether rotating credentials or switching to a different Conductor account — leaves every user's cached account ID pointing at the old account until natural cache expiry.
issue