Quand deux MCPs appellaient login, le second appelait bw unlock et générait
un nouveau token, invalidant celui du premier. Deux mécanismes corrigent ça :
1. LoginBitwarden ne relance plus bw unlock si le vault est déjà unlocked
et qu'une session existe (env, fichier service, ou fichier partagé).
2. Le login écrit le token dans ~/.config/mcp-framework/bw-session (partagé)
en plus du fichier service-spécifique. Les autres MCPs lisent ce fichier
en priorité via refreshSessionEnv avant chaque opération Bitwarden.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Quand un MCP appelle login/unlock, le token est écrit dans le fichier de session
mais les autres MCPs conservent leur token obsolète dans l'environnement du processus.
Désormais, bitwardenStore.ensureReady() appelle refreshSessionEnv() qui relit le
fichier avant chaque vérification, ce qui permet à tous les MCPs de rester
opérationnels après une rotation de session.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
