docs(architecture): remove derive_password and site_password_path from vault

The password-manager pattern (deterministic per-site passwords from HD
derivation) is not relevant to an RPC system's vault. Handlers call APIs
(using API keys, OAuth tokens, mTLS), not websites with passwords. The
vault is for cryptographic key derivation and credential encryption.

Removes:
- derive_password, derive_password_string from service.md
- site_password_path from mnemonic-derivation.md
- m/74'/1'/0'/{hash}' path from PATHS module and path semantics table
- derive_password row from the cache table

Resolves review #002 C9 (site_password_path hash mapping underspecified)
by removing the feature rather than specifying the non-standard
string→u32 mapping and Ed25519-as-password-entropy construction.

If deterministic password generation is ever needed (browser-automation
edge case), it can be re-added — the cost is near-zero. Removing it now
eliminates permanent API surface inherited from a prior project's
password-manager pattern.

docs/architecture/decisions/019-vault-assembly-layer-only.md

@@ -20,8 +20,8 @@ perspective?**
 
 The vault provides a `VaultServiceHandle` with `unlock`, `lock`,
 `derive_ed25519`, `derive_encryption_key`, `derive_ethereum_key`,
-`derive_password`, `encrypt`, and `decrypt` methods. Who is allowed to call
-these, and through what path?
+`encrypt`, and `decrypt` methods. Who is allowed to call these, and
+through what path?
 
 The candidates: