core: refuse an account index BIP-32 cannot harden, whichever way it arrives

The counter path checked it, the explicit one did not, and the parser is not
the only caller: processChatCommand takes APIWalletBind from library callers
too. hardened leaves an index at or above 2^31 alone, so account i and
i + 2^31 are the same key while the duplicate check compares the stored
integers, and two profiles could hold one account's names.

The rfc now says what hiding a profile from /_wallet does and does not
protect: the seed is one per device, so whoever unlocks any profile can
derive every account.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rvc3HbiWBTqbAvRT45G5oX

docs/rfcs/2026-09-10-name-ownership-keys.md

@@ -124,6 +124,18 @@ import, so `/_wallet bind` with no account can hand out one that already owns
 names. Only a scan of owned names can restore the mark, and that lands with the
 registrar.
 
+## Hidden profiles
+
+`/_wallet` names the other profiles on the seed and never numbers them, so a
+hidden profile leaves no gap in a list of account indexes.
+
+That hides its existence from the listing, and nothing more. The seed is one per
+device, so whoever unlocks any profile can export the phrase and derive every
+account, including a hidden profile's. A hidden profile's names are not
+pseudonymous against someone who already holds the device and one password. This
+is a consequence of one seed per device, and a key per profile rather than per
+device is what would change it.
+
 ## Scope
 
 Not here, and unchanged from the prototype: buying a name, the names protocol,