Refactor PolarisException status mapping into PolarisException hierarchy

[flyrain]

Is your feature request related to a problem? Please describe.

Summary

Today, PolarisExceptionMapper is responsible for mapping every PolarisException subtype to an HTTP Response.Status. This creates coupling between the mapper and every exception type.

Proposal

Invert this relationship by making PolarisException define a required method that returns its corresponding Response.Status. Each exception subclass would provide its own status, allowing PolarisExceptionMapper to delegate to the exception instead of maintaining a centralized mapping.

Benefits include:

• Reduces coupling between PolarisExceptionMapper and exception implementations.
• Makes it easier to add new exception types without modifying the mapper.
• Keeps the HTTP status semantics alongside the exception definition.

This is a follow up to the discussion in PR #4961.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[harshitaajoshi]

Hi, I would like to work on this. My plan is to add a default httpStatusCode() method on PolarisException returning 500, then override it in each subclass with the correct status code. This keeps jakarta.ws out of polaris-core by using plain int. The mapper would then delegate to exception.httpStatusCode() instead of maintaining the switch statement. I will include a parameterized test covering all subclasses. Happy to adjust based on feedback :)