feat(log): Gin 改结构化 JSON 访问日志 + 保留期自动清理（含 VACUUM 回收）

=== 一、审计结论（用户问：gin 日志是否标准、会不会打爆磁盘）===
现状是标准的：gin.Default() 写 stdout，代码里没有任何
gin.DefaultWriter / log.SetOutput / lumberjack / os.OpenFile 写日志文件；
容器内 /var/log 是空的，find / -name "*.log" 无结果；
kubelet containerLogMaxSize=10Mi / containerLogMaxFiles=5 自动轮转，
实测 /var/log 只占 120G 磁盘的 0.8%。

但发现两个真问题：
  1. 访问日志是 gin 默认文本格式，Loki 里没法按字段过滤
  2. 审计日志/查询历史等只配了保留天数，**没有任何自动清理** ——
     只有手动按钮，表会一直涨，SQLite 文件删了也不缩

=== 二、结构化 JSON 访问日志（middleware/accesslog.go）===
gin.Default() → gin.New() + AccessLog() + gin.Recovery() + CORSMiddleware
  - 一行一个 JSON：ts/level/type/method/path/status/latency_ms/bytes/ip/ua
  - 自动分级：5xx=error / 4xx=warn / 其余=info
  - 鉴权后带 user_id / username，便于审计
  - 健康检查与 /assets 静音（K8s 探针每 10s 一次，会淹没真实请求）
  - Recovery 显式加回（gin.Default 里包含它，漏了 panic 会打挂进程）

⚠️ 关键细节：Go 的 map 序列化按 key 字母序，ts 会排到最后，
   一行以 {"bytes":... 开头根本看不出时间。LogJSON 手工拼装，
   把 ts/level/type/msg 固定在最前，其余排序输出。

=== 三、保留期自动清理（handler/cleanup.go）===
启动 2 分钟后跑一次，之后每 24h 一次；cleanup_auto_enabled=false 可关。

覆盖 8 张会无限增长的表（原来只管 4 张）：
  audit_logs / query_histories / slow_logs / tickets
  + operation_logs / workflow_execution_logs / scheduled_task_logs（新增）
  + refresh_tokens（按 expires_at < now，过期不清理会每次登录加一行）

设计取舍：
  - 每批删 5000 行、批间 sleep 50ms：SQLite 单写者，一条 DELETE 全删会把库锁死
  - 单表单轮最多 20 万行，剩下的留给下一轮
  - deleted 后看 freelist/page_count，>25% 才 VACUUM（DELETE 不还磁盘，必须 VACUUM）
  - 保留天数 <=0 视为不清理，避免误配把数据全删

手动接口同步改造：/settings/cleanup/{preview,run} 复用同一套逻辑，
返回结构改为 {deleted, total, vacuumed, freed_bytes, cost_ms}。

新增系统设置（seed 自动补，已实测 8 个 key 全部落库）：
  operation_log_retention_days=365  workflow_log_retention_days=180
  scheduled_log_retention_days=180  cleanup_auto_enabled=true

=== 四、实测 ===
访问日志：{"ts":"2026-10-27T14:46:39.58Z","level":"info","type":"access","bytes":668,"ip":"...","latency_ms":78.6,"method":"POST","path":"/api/v1/auth/login","status":200,...}
health 日志行数: 0 ✅   [GIN] 文本行数: 0 ✅   非 JSON 行: 4（仅启动）
cleanup preview: 8 张表的 count/days ✅
cleanup run: {"cost_ms":1,"deleted":{},"freed_bytes":0,"vacuumed":false,"total":0} ✅

镜像：lghost/opsxsql:latest + v0.1 = sha256:30593de3fc09

backend/cmd/server/main.go

@@ -1,6 +1,7 @@
 package main
 
 import (
+	"context"
 	"fmt"
 	"log"
 	"net/http"
@@ -9,6 +10,7 @@ import (
 	"strings"
 
 	"sql-platform/config"
+	"sql-platform/internal/handler"
 	"sql-platform/internal/middleware"
 	"sql-platform/internal/model"
 	"sql-platform/router"
@@ -75,8 +77,13 @@ func main() {
 	config.EnsureJWTSecret()
 
 	// Setup Gin
-	r := gin.Default()
-	r.Use(middleware.CORSMiddleware())
+	//
+	// 用 gin.New() 而不是 gin.Default()：Default 自带的是文本格式的 gin.Logger()，
+	// 这里换成结构化 JSON 访问日志（middleware.AccessLog），便于 Promtail→Loki 按字段过滤，
+	// 同时跳过健康检查/静态资源，避免探针轮询把日志量刷满。
+	// Recovery 必须显式加回来（Default 里包含它），否则 panic 会打挂整个进程。
+	r := gin.New()
+	r.Use(middleware.AccessLog(), gin.Recovery(), middleware.CORSMiddleware())
 
 	// Health check
 	r.GET("/health", func(c *gin.Context) {
@@ -86,6 +93,11 @@ func main() {
 	// Routes
 	router.Setup(r)
 
+	// 后台保留期清理：启动 2 分钟后跑第一次，之后每 24h 一次。
+	// 解决「只配了保留天数但没人执行」的问题 —— 之前审计日志/查询历史
+	// 只能靠管理员手动点「立即清理」，表会一直涨、SQLite 文件也不会缩。
+	handler.StartCleanupScheduler(context.Background())
+
 	// 单镜像部署:直接托管前端产物(DIST_DIR 为空则跳过,开发模式由 vite 独立提供)
 	if distDir := os.Getenv("DIST_DIR"); distDir != "" {
 		indexPath := filepath.Join(distDir, "index.html")
@@ -145,6 +157,10 @@ func seedDefaultSettings(db *gorm.DB) {
 		{Key: "audit_log_retention_days", Value: "365", ValueType: "number", Group: "cleanup", Label: "审计日志保留天数", Desc: strPtr("超过此天数的审计日志将被清理"), DefaultValue: strPtr("365"), SortOrder: 2},
 		{Key: "query_history_retention_days", Value: "90", ValueType: "number", Group: "cleanup", Label: "查询历史保留天数", Desc: strPtr("超过此天数的查询历史将被清理"), DefaultValue: strPtr("90"), SortOrder: 3},
 		{Key: "slow_log_retention_days", Value: "180", ValueType: "number", Group: "cleanup", Label: "慢日志保留天数", Desc: strPtr("超过此天数的慢查询日志将被清理"), DefaultValue: strPtr("180"), SortOrder: 4},
+		{Key: "operation_log_retention_days", Value: "365", ValueType: "number", Group: "cleanup", Label: "操作日志保留天数", Desc: strPtr("超过此天数的操作日志将被清理"), DefaultValue: strPtr("365"), SortOrder: 5},
+		{Key: "workflow_log_retention_days", Value: "180", ValueType: "number", Group: "cleanup", Label: "工单流程日志保留天数", Desc: strPtr("超过此天数的工单流程执行日志将被清理"), DefaultValue: strPtr("180"), SortOrder: 6},
+		{Key: "scheduled_log_retention_days", Value: "180", ValueType: "number", Group: "cleanup", Label: "定时任务日志保留天数", Desc: strPtr("超过此天数的定时任务执行日志将被清理"), DefaultValue: strPtr("180"), SortOrder: 7},
+		{Key: "cleanup_auto_enabled", Value: "true", ValueType: "boolean", Group: "cleanup", Label: "自动清理", Desc: strPtr("每天自动按上面的保留天数清理一次；关闭后仍可在本页点「立即清理」"), DefaultValue: strPtr("true"), SortOrder: 99},
 
 		// ── 执行器 ──
 		{Key: "executor_timeout", Value: "300", ValueType: "number", Group: "executor", Label: "执行超时(秒)", Desc: strPtr("工单中 SQL 语句执行的最大等待时间"), DefaultValue: strPtr("300"), SortOrder: 1},