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>
À chaque tag stable, la CI extrait la section [Unreleased], l'utilise
comme notes de release Forgejo, renomme la section avec la version et
la date, puis commite le CHANGELOG.md mis à jour sur main.
Les tags RC utilisent le contenu [Unreleased] pour les notes mais ne
modifient pas le fichier.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
