Add --limit option to cap URLs processed

[ewertones]

Summary

• Adds a --limit N / limit option that stops the URL-processing loop after N URLs.
• Most useful for batching large input files when combined with --database-path to avoid Spotify's anti-abuse rate limits on long runs.
• No behavioral change when the flag is unset (default null = unlimited).

Motivation

On a 450-URL input, the run hit Client token request failed with status code 400 after ~100 successful tracks — matching the account-suspension warning already in the README. With --limit 50 --database-path downloaded.db --wait-interval 30, a large job can be split across sessions: failures aren't recorded in the DB so they're retried automatically; successes are skipped. This makes very long input lists practical without tripping Spotify's abuse detection.

Implementation is intentionally minimal: +12 lines across the CLI config dataclass, the outer URL loop in cli.main, and the README options table. Nothing in the API, interface, or downloader layers is touched.

Test plan

• votify --help shows --limit INTEGER with the new help text in the General group.
• Loop break logic verified for limit ∈ {None, 0, 1, 3, 5, 99} against a 5-URL list — all edge cases behave correctly (no break, break before first iteration, break mid-list, exact boundary, value greater than total).

🤖 Generated with Claude Code