Bug: ows wallet delete --confirm bypasses all protections

Summary

ows wallet delete --confirm deletes wallets with no meaningful safety gate. The policy engine, filesystem permissions, and directory write protections are all bypassed.

Steps to Reproduce

1. Create a wallet: ows wallet create --name test
2. Register a deny policy that should block deletion
3. chmod 500 the wallets directory to make it read-only
4. Run ows wallet delete --wallet test --confirm
5. Wallet is deleted. Directory permissions are restored to writable and the file is unlinked.

Expected Behavior

At least one of these should protect against accidental or unauthorized wallet deletion:

• Policy engine: Wallet lifecycle operations (create/delete) should be routable through the policy engine, the same way signing operations are. Currently, PolicyRule only gates transaction, typed_data, and spending — there's no way to deny wallet deletion via policy.
• Filesystem permissions: If the vault directory is chmod 500, deletion should fail rather than restoring write permissions.
• Confirmation: --confirm is a flag, not a prompt. Any script or agent can pass it. There's no interactive "are you sure?" step and no password/key verification.

Why This Matters

In agent-first workflows (which OWS explicitly targets — see the Agent Access Layer in the spec), AI agents with shell access can destroy wallets irreversibly with a single command. There's no recovery path because:

• The --confirm flag provides no authentication
• The policy engine doesn't cover lifecycle operations
• The CLI modifies filesystem permissions to force deletion
• No mnemonic backup prompt or warning is shown before deletion

Environment

• OWS v1.3.2
• Linux arm64 (Raspberry Pi)
• Wallet stored in default vault at ~/.ows/wallets/

Suggested Fixes

1. Route wallet lifecycle operations through the policy engine (add wallet_delete as a policy-checkable operation)
2. Require key verification (e.g., signing a challenge with the wallet's key) before allowing deletion
3. Respect filesystem permissions — if the vault directory is read-only, fail with a clear error instead of restoring write access
4. Add a --force flag that's required when --confirm is used non-interactively, making it harder to accidentally delete in scripts