Ask for the new passphrase in unlocker add when the variable is set (closes #154)

With SB_UNLOCK_PASSPHRASE set, `secret unlocker add passphrase` gave the
new unlocker the passphrase in the variable without asking. It now asks
on the terminal for the new passphrase and uses the variable only to
unlock the vault. With no controlling terminal the new unlocker takes
the variable's passphrase, as before, and the output says so.

secret.ErrNoTerminal is exported so that the command can tell a missing
terminal from other failures to read, such as nothing typed or a
mismatched confirmation, which still fail the command.

The in-process tests that add a passphrase unlocker with the variable
set rely on the Docker test phase having no controlling terminal; at a
terminal they would ask.

Model: opus-5-5

TODO.md

@@ -18,6 +18,15 @@ https://git.eeqj.de/sneak/secret/milestone/12
 
 # Completed Steps
 
+- 2026-10-14: `secret unlocker add passphrase` asks on the terminal for the new
+  passphrase when `SB_UNLOCK_PASSPHRASE` is set, and unlocks the vault with the
+  variable (https://git.eeqj.de/sneak/secret/issues/154). It used to give the
+  new unlocker the passphrase in the variable without asking, so a user who set
+  it only to unlock the vault was left with the old passphrase and not told.
+  With no controlling terminal the new unlocker still takes the variable's
+  passphrase, and the command now says so. `secret.ErrNoTerminal`, exported for
+  this, is wrapped in the error `ReadPassphrase` and `ReadMnemonic` return when
+  there is no terminal.
 - 2026-10-14: A wrong passphrase, from `SB_UNLOCK_PASSPHRASE` or typed at the
   prompt, gives the error `wrong passphrase for unlocker <id>`
   (https://git.eeqj.de/sneak/secret/issues/157). It used to be age's "no