The Gin engine is initialized without a recovery middleware, causing connection drops on panic

Inizia da internal/base/server/http.go, all’inizializzazione di gin.New(), quindi leggi internal/base/handler/handler.go per le convenzioni relative alle risposte di errore standard e al logging. Riproduci un panic in un handler come descritto e verifica che il server restituisca la risposta JSON 500 unificata con reason base.unknown, registrando al contempo il panic e lo stack trace.

Describe the bug

In internal/base/server/http.go, the Gin engine is initialized via gin.New() without mounting a recovery middleware. When a panic occurs in any handler or middleware, the connection is dropped without returning a proper HTTP response to the client.

Current behavior

gin.New() (unlike gin.Default()) does not install any recovery middleware. When a panic propagates out of a handler:

• The Go runtime's net/http server recovers per-connection, preventing the process from exiting.
• But it closes the connection without writing any response body.
• The client sees a connection reset / EOF rather than a structured 5xx response.
• The panic is not logged through the project's logging facility (pacman/log).

To Reproduce

This is a defensive coding issue rather than a directly triggerable bug. To verify the behavior, one can temporarily add panic("test") to any controller handler and observe that the client receives a connection error instead of an HTTP response.

Expected behavior

The server should return a unified 500 JSON response with reason: base.unknown, consistent with how other errors are handled in the project (see internal/base/handler/handler.go). The panic message and stack trace should be logged via the project's logger for diagnostics.

Additional context

I'd like to submit a PR to fix this by adding a middleware.Recovery() that:

• Logs the panic message and full stack trace via log.Errorf + debug.Stack().
• Returns the standard error response using handler.NewRespBody + TrMsg to stay consistent with the rest of the codebase.
• Is mounted as the first middleware in http.go so it covers all subsequent middleware and handlers.