feat(sources): allow editing CalDAV sources (URL, username, password, name)

[olivierlambert]

Summary

Closes #72. Today the source row at `/dashboard/sources` supports test, sync, remove, and write-back-calendar selection — but not editing the connection itself. Typo'd URL? Username mistake? Periodic CalDAV password rotation? The only path was delete-and-readd, which loses the synced events cache, the write-back configuration, and any per-event-type calendar selections that referenced calendars under the old source.

This PR adds an Edit affordance on each source row (web) and a `calrs source update` command (CLI). Both are scoped to the current user's sources.

Web

• New routes: `GET /dashboard/sources/{id}/edit` (form pre-filled from DB) and `POST /dashboard/sources/{id}/edit` (apply changes).
• New "Edit" link added to each source row in `templates/dashboard_sources.html`, between Test and Remove.
• `templates/source_form.html` reused with an `editing` boolean (mirrors the `event_type_form.html` pattern). When editing: the title/subtitle change, the password field is no longer `required` and shows "Leave blank to keep existing", and the form posts to the edit URL.
• The handler scopes by `user_id` on both GET and POST, so you can't view or edit a source you don't own (redirect to `/dashboard/sources` on mismatch).

CLI

`calrs source update [--name ...] [--url ...] [--username ...] [--password]`

• `` accepts a unique prefix (matching the existing convention in `Remove` and `Test`).
• `--password` is a boolean flag; when set, the command prompts for the new password via `rpassword` (no echo, not in shell history). Useful for scripted password rotation.
• Without `--password` the existing encrypted blob is preserved untouched.

Notable details

• Password field is optional in both surfaces; empty means "keep existing". The web handler decrypts the stored blob to feed the connection-test client with the same credentials sync will use afterwards, so the test exercises the real auth path.
• URL still passes `validate_caldav_url` (the existing SSRF guard) regardless of whether the connection test is skipped.
• The "Skip connection test" checkbox still works on the edit form — same semantics as create.
• After URL or username changes, both surfaces hint that a manual sync is recommended to refresh the discovered calendar list. No automatic re-sync — the discovery flow's `resolve_url()` already re-resolves hrefs from the server origin, so the next manual sync self-heals.

Tests

4 new web handler tests:

• `edit_source_form_renders_prefilled` — GET shows form in editing mode with name/url/username pre-filled, password placeholder reads "Leave blank to keep existing"
• `update_source_changes_fields_and_keeps_password_when_blank` — POST with empty password updates name/url/username, decrypted password unchanged
• `update_source_rotates_password` — POST with non-empty password re-encrypts; decrypted blob matches new password
• `update_source_404_for_other_user_source` — GET on another user's source redirects (cross-user scoping enforced)

583 tests total (up from 579). All green on pre-commit. Clippy clean.

Test plan

• On `/dashboard/sources`, click Edit on an existing source. Form pre-fills with current values; password field shows "Leave blank to keep existing".
• Change the display name, leave password blank, save. Source name updates; sync still works (proving password unchanged).
• Edit again, enter a new password, save. Manual sync should still work (proving password rotation succeeded). If you rotate to a wrong password and the test wasn't skipped, the form re-renders with a connection-failed error.
• Try the CLI: `calrs source update --name "New Name"` (no password change) and `calrs source update --password` (interactive prompt).
• After editing the URL or username, verify the post-action hint says to run sync.

Verification gap I'm flagging

I have not driven the Edit button in a real browser. The handler logic is covered by the four unit tests on `update_source` plus the existing template-render tests; the JS-free form is unlikely to surprise. The browser-facing piece worth eyeballing is the post-edit redirect and the password-blank "Leave blank to keep existing" placeholder.

🤖 Generated with Claude Code