Code Review: Message Handling & Link Detection

Scope

Regex detection is consolidated in one place; uses a single pattern for all supported services.
Resolver encapsulates the idonthavespotify API and wraps errors with context.
Output formatting is consistent and service ordering is explicit.

Detector misses some common URL variants
- Apple Music URLs can include music.apple.com/{country}/album/... but also have track URLs and other forms not matched.
- Spotify short links (https://spoti.fi/...) are not detected.
- Consider adding more variants or making the detector extensible with service-specific regexes.
Detector does not parse Markdown/HTML links
- Matrix formatted_body or Slack-style <url|text> formats won’t be parsed, only raw URLs.
- Consider optional parsing of formatted content if available.
Resolver only processes the first link
- Handler selects links[0], ignoring additional links in the message.
- Consider responding to multiple links or clarifying this behavior in docs.
API error handling omits response body
- Resolve returns API returned status %d without details, making debugging harder.
- Consider reading up to N bytes of body on error for logging.
Service mapping lacks Qobuz even though enum exists
- ServiceQobuz defined but never populated; detector/formatting do not include it.
- Consider either supporting or removing it to avoid dead config.

Formatting uses title for track only; artist metadata is not used even if present (currently not parsed from API response).