Let apps shape the fingerprint, so a message with a per-request id doesn't split one error into many

Start by reading Subscriber#report and the fingerprint configuration path; the issue names these as the likely change points but does not give file paths or tests. Compare the proposed configurable fingerprint hook with the narrower message-normalizing option, then check the README and existing subscriber tests. Done means the chosen option groups messages with changing request IDs while retaining the reported message, with configuration documented and tests covering the behavior.

An error's fingerprint is a hash of its class, message, severity and source. When a message embeds something that changes with every occurrence, such as a request id, a record id or a timestamp, each occurrence becomes an error of its own. The dashboard fills with near-identical errors that each have one occurrence. That hides a real outage, which looks like hundreds of new errors rather than one error with hundreds of occurrences, and since every one is "new", each one is emailed.

The case we hit is API client errors that end with the provider's request id:

Anthropic::Errors::InternalServerError: Internal server error (request_id: req_011CT8...)

What we do today is wrap the subscriber. We unsubscribe SolidErrors::Subscriber and subscribe one that rewrites the exception's message, replacing req_... with a placeholder and moving the id into the context, before handing it on. It works, but it means replacing the gem's subscriber and redefining #message on the exception.

A possible shape: an optional hook that turns the attributes into the fingerprint, defaulting to what happens now:

config.solid_errors.fingerprint = ->(error:, attributes:) {
  message = attributes[:message].gsub(/\breq_[A-Za-z0-9]+/, "req_*")
  [attributes[:exception_class], message, attributes[:severity], attributes[:source]].join
}

The stored message would stay as reported, so the id is still there to quote, and only the grouping would change. A narrower alternative is a message-normalizing proc that applies only to the fingerprint.

Would something like this be welcome? If so, I can send a small PR: the config option, the call in Subscriber#report, a README section and tests.