security: harden credential handling, SSRF protection, and key storage

[orsharon7]

Summary

This PR fixes several security issues identified during a review of the credential handling flow. The app stores bank credentials and API keys, so these are high-priority hardening items.

• Password masking -- GET /api/integrations/[provider] was returning fully decrypted credentials including passwords. Now returns empty strings for password-type fields. The edit form already had blank=keep logic in the POST handler, so no functionality is lost. Password inputs show "Leave blank to keep current" as placeholder in edit mode, and allValid allows blank passwords when editing.
• Provider validation -- POST /api/setup/bank now rejects unknown provider values (400) before touching the database.
• SSRF protection -- Both PUT /api/settings and POST /api/setup/ai now validate that ollamaUrl is a localhost URL before storing it. Previously any URL could be saved and the server would make outbound requests to it.
• Encryption key location -- The key was stored in data/.encryption-key, the same directory as data/spent.db. Anyone with a copy of that directory could decrypt all credentials. The key now lives at ~/.config/spent/.encryption-key. Existing keys are migrated automatically on first startup.
• Verbose log warning -- The "Show browser during sync" setting description now explicitly warns that logs may contain bank credentials and should not be shared.

Test plan

• Edit an existing bank connection -- password field is blank with "Leave blank to keep current" placeholder; saving without retyping keeps the old password
• POST to /api/setup/bank with an unknown provider name -- should return 400 "Unknown provider"
• PUT to /api/settings with ollamaUrl pointing to a non-localhost address -- should return 400
• Confirm ~/.config/spent/.encryption-key is created on first run (mode 600) and data/.encryption-key is absent
• Existing synced data is still readable after the key migration

🤖 Generated with Claude Code