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

## 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.

Start in internal/base/server/http.go at the gin.New() initialization, then read internal/base/handler/handler.go for the standard error response and logging conventions. Reproduce a handler panic as described and verify that the server returns the unified 500 JSON response with reason base.unknown while logging the panic and stack trace.

Written by the indexing model from the issue text.