[FEATURE] Configuration enhancement: artist/album blocklist

[lcyvin]

Is your feature request related to a problem? Please describe.
Certain artists or albums present within a library may match enough features due to their varied instrumentation, tempo, etc. such that they are overrepresented in playlist generation output. For instance,within my own library of ~12,000 tracks, with a reasonably distributed featureset [see image], several artists and albums are frequently included in mixes sourced from tracks ranging from Metal to Electronic to Jazz. While I enjoy these artists or albums on their own, their over-representation in playlist output can be fatiguing, and at times jarring.

Short of outright removing the tracks from the library entirely, I see no current methodology to prevent their over-inclusion. An ability to outright block certain artist's inclusion from generated playlists wholesale, or from certain featuresets, would be beneficial.

Using existing tools, if I were to -- for instance -- create a song alchemy playlist using A number of Electronic and Rock songs, inclusion of one particular commonly appearing track would block several hundred otherwise valid results.

Describe the solution you'd like
I see a handful of methods for addressing the problem:

1. Inclusion of a configuration file/data payload listing indexed artists to be blocklisted from playlist results, without effecting the overall delete/avoid centroids

or

2. Blocklist ability within application interfaces themselves which do not enforce a centroid but rather only prevent addition of a specific artist/album/etc. to a generated playlist.

Describe alternatives you've considered
At this time, short of outright removing the artists/albums in question from the library, I do not see a viable workaround method for reducing the tracks' over-representation in playlist output.

Additional context
This may also be somewhat addressable through user reinforcement/feedback of model outputs, either by rating the scored features or by flagging the individually included items in playlist output in the web view. It's also possible that additional features and genres being represented in the model may help, as several of these over-represented artists fit genres which are not present within the list (E.G., one commonly included track is in the Ska genre, with heavy electronic instrumentation). Machine learning matrices are not my area of expertise, however, so further analysis behind the over-inclusion is somewhat over my head.

[sylvesterboris]

Implemented an artist/album blocklist to reduce over-representation of certain artists in generated playlists and improve listening diversity without removing tracks from the library; added a PostgreSQL blocklist table supporting artist and album entities with case-insensitive normalization, global or feature-specific scope, enable/disable status, and indexed fields for performance; implemented an in-memory, set-based cache that loads on startup and auto-refreshes on updates, providing O(1) lookups with minimal memory usage and <1% playlist-generation overhead; built REST APIs for full CRUD operations including fetch, add, delete, enable/disable, and artist autocomplete search, with automatic cache refresh on all changes; integrated filtering into Song Alchemy via a reusable filter_by_blocklist() helper applied after centroid calculation and before final selection to fully exclude blocklisted artists without affecting recommendation logic; added a responsive blocklist management UI with artist autocomplete (including track counts), real-time add/remove/toggle actions, status indicators, and empty-state messaging aligned with existing AudioMuse-AI design patterns; introduced a BLOCKLIST_ENABLED environment variable for global enable/disable during testing or debugging; feature is fully functional and tested for Song Alchemy, with immediate effect on generated playlists, and the helper is ready for extension to similarity search, path generation, and clustering features (manual verification recommended due to file complexity).