Ask for the mnemonic and passphrase before taking the state directory lock (closes #152)

init, vault create, unlocker add, and add, import and generate secret
with --force asked for the mnemonic or passphrase, or unlocked the
vault, while holding the state directory lock, so every other command
that changes anything waited at the prompt. They now ask and unlock
first and lock after. Under the lock, unlocker add fails if the vault
was removed, or created again with another key, and refuses a GPG key
added meanwhile; a forced add of a secret created meanwhile lets go of
the lock, gets the key and locks again. secret.CreatePGPUnlocker takes
the unlocked vault; SetMnemonic and SetUnlockPassphrase are gone.

Not done: secret move between vaults still unlocks both under the lock
(#189).

Model: opus-5-5

internal/cli/unreadable_dir_test.go

@@ -9,11 +9,12 @@
 // "nothing there" and go ahead.
 //
 // The tests make the look fail with a wrapper around the in-memory
-// filesystem, which the state directory lock refuses. So they call the
-// function each command runs once it holds the lock, such as addPGPUnlocker
-// for UnlockersAdd, or, for a removal, the function that makes its checks,
-// such as findVaultToRemove for RemoveVault, which runs again under the
-// lock before anything is removed, with --force or without.
+// filesystem, which the state directory lock refuses. So they call a
+// function that makes the look before any lock is taken: addPGPUnlocker for
+// UnlockersAdd, which looks again once it holds the lock, or, for a removal,
+// the function that makes its checks, such as findVaultToRemove for
+// RemoveVault, which runs again under the lock before anything is removed,
+// with --force or without.
 
 //nolint:testpackage // white-box test of unexported internals
 package cli