fix(docs): say an orphaned hook is no longer bounded after Ctrl+C

docs/site/docs-en/configuration/config-file.md

@@ -808,7 +808,7 @@ For the once-per-run hooks (`preRelease`, `onSuccess`, `onError`) the per-packag
 
 `onFailure` is the failure **strategy** (`abort` / `continue`), not a command. The command that runs _when_ a release fails is `onError`, which receives the failing `FERRFLOW_ERROR_CODE`.
 
-Hooks run with stdin closed, so a command that would prompt (`npm login`, a `gpg` passphrase, a git credential prompt) fails at once instead of waiting forever. A hook still running after `timeout` seconds is killed along with any process it started, and counts as a failed hook: `abort` stops the release, `continue` warns and moves on. Every minute a long hook prints that it is still running. Set `timeout` per package to override the workspace value. On Linux and macOS a hook runs in its own process group so it can be killed with everything it started, which also means a Ctrl+C on an interactive `ferrflow release` stops FerrFlow but not a hook that is already running; the timeout still bounds it.
+Hooks run with stdin closed, so a command that would prompt (`npm login`, a `gpg` passphrase, a git credential prompt) fails at once instead of waiting forever. A hook still running after `timeout` seconds is killed along with any process it started, and counts as a failed hook: `abort` stops the release, `continue` warns and moves on. Every minute a long hook prints that it is still running. Set `timeout` per package to override the workspace value. On Linux and macOS a hook runs in its own process group so it can be killed with everything it started, which also means a Ctrl+C on an interactive `ferrflow release` stops FerrFlow but not a hook that is already running, and since the timeout is enforced by FerrFlow itself, that hook then runs until it finishes on its own.
 
 ### Per-package hooks
 

docs/site/docs-fr/configuration/config-file.md

@@ -667,7 +667,7 @@ Pour les hooks exécutés une seule fois par run (`preRelease`, `onSuccess`, `on
 
 `onFailure` est la **stratégie** d'échec (`abort` / `continue`), pas une commande. La commande exécutée _quand_ une release échoue est `onError`, qui reçoit le `FERRFLOW_ERROR_CODE` fautif.
 
-Les hooks s'exécutent avec stdin fermé : une commande qui poserait une question (`npm login`, une passphrase `gpg`, une demande d'identifiants git) échoue tout de suite au lieu d'attendre indéfiniment. Un hook encore en cours après `timeout` secondes est tué avec les processus qu'il a lancés, et compte comme un hook en échec : `abort` arrête la release, `continue` affiche un avertissement et poursuit. Chaque minute, un hook long indique qu'il tourne toujours. `timeout` défini sur un package remplace la valeur du workspace. Sous Linux et macOS, un hook tourne dans son propre groupe de processus pour pouvoir être tué avec tout ce qu'il a lancé : un Ctrl+C sur un `ferrflow release` interactif arrête donc FerrFlow mais pas un hook déjà en cours, qui reste borné par son timeout.
+Les hooks s'exécutent avec stdin fermé : une commande qui poserait une question (`npm login`, une passphrase `gpg`, une demande d'identifiants git) échoue tout de suite au lieu d'attendre indéfiniment. Un hook encore en cours après `timeout` secondes est tué avec les processus qu'il a lancés, et compte comme un hook en échec : `abort` arrête la release, `continue` affiche un avertissement et poursuit. Chaque minute, un hook long indique qu'il tourne toujours. `timeout` défini sur un package remplace la valeur du workspace. Sous Linux et macOS, un hook tourne dans son propre groupe de processus pour pouvoir être tué avec tout ce qu'il a lancé : un Ctrl+C sur un `ferrflow release` interactif arrête donc FerrFlow mais pas un hook déjà en cours, et comme le timeout est appliqué par FerrFlow lui-même, ce hook tourne alors jusqu'à ce qu'il se termine de lui-même.
 
 ### Hooks par package