[FEATURE] Include release year in `rip search -o` JSON output

[cargaona]

Is the feature request related to a problem. Please describe it.

When using rip search <source> album <query> -o results.json to get search results as JSON for scripting/automation, the output only contains source, media_type, id, and desc. It does not include the release year, even though the year is already extracted internally from the source API responses (via date_released in AlbumSummary/TrackSummary). Consumers that need to display or filter by year (e.g. a Telegram bot, a web UI) currently have no way to get it without making a separate metadata lookup for each result.

Describe the solution you would like.

Add a year field to the JSON objects returned by rip search -o. The year data is already parsed by AlbumSummary.from_item() and TrackSummary.from_item() into the date_released field — it just needs to be surfaced in SearchResults.as_list().

Specifically:

• Add an abstract year property to the Summary base class.
• Implement on AlbumSummary and TrackSummary by extracting the first 4 characters of date_released (e.g. "1977" from "1977-02-04"), returning null if unavailable.
• Implement on ArtistSummary, LabelSummary, PlaylistSummary returning null (no year concept).
• Add "year": i.year to the dict in as_list().

The output would look like:

[
    {
        "source": "deezer",
        "media_type": "album",
        "id": "302127",
        "desc": "Dark Side of the Moon by Pink Floyd",
        "year": "1973"
    }
]

Backward compatible — existing consumers ignore unknown keys. No new API calls or dependencies needed.

Describe alternatives you've considered.

• Post-processing the desc field to extract a year (fragile, not present in desc).
• Making a separate rip id / metadata API call per result to get the year (slow, defeats the purpose of batch search output).
• Parsing the year from the interactive terminal menu output (not machine-friendly).
• Adding year as an integer — keeping it as str | null is more consistent with the existing all-string dict type and avoids JSON type coercion issues.