[Bug]: slim 镜像切换后媒体处理配置与缩略图有效能力不一致

[AptS-1547]

What happened?

从包含 libvips/FFmpeg 的完整 Docker 镜像切换到 slim 镜像时，数据库里已有的媒体处理配置不会被 slim 镜像的 bootstrap 环境变量覆盖。因此可能出现以下状态：

• vips_cli.enabled = true，配置的扩展列表仍包含 heic、heif 等格式；
• 当前容器里实际找不到 vips 命令；
• 已经生成并缓存的旧缩略图仍然可以读取；
• 新上传的同格式图片无法生成缩略图；
• 管理端显示的是持久化配置，而 /public/thumbnail-support 返回的是经过命令可用性过滤后的有效能力，两者看起来互相矛盾。

现场曾观察到一份不包含 heic 的缩略图能力响应：

{
  "code": "success",
  "msg": "",
  "data": {
    "version": 1,
    "image_preview": {
      "enabled": true,
      "extensions": ["apng", "bmp", "exr", "ff", "gif", "hdr", "ico", "jfif", "jpeg", "jpg", "pam", "pbm", "pgm", "png", "pnm", "ppm", "qoi", "tga", "tif", "tiff", "webp"]
    },
    "image_thumbnail": {
      "enabled": true,
      "extensions": ["apng", "bmp", "exr", "ff", "gif", "hdr", "ico", "jfif", "jpeg", "jpg", "pam", "pbm", "pgm", "png", "pnm", "ppm", "qoi", "tga", "tif", "tiff", "webp"]
    },
    "audio_thumbnail": {
      "enabled": true,
      "extensions": ["aac", "aif", "aiff", "ape", "flac", "m4a", "m4b", "m4p", "m4r", "mp3", "ogg", "opus", "wav", "wv"]
    },
    "video_thumbnail": {
      "enabled": false
    }
  }
}

这份响应适合用来讨论接口语义，但不足以单独证明某个部署当前使用了 slim 镜像。部署诊断仍需同时核对镜像 digest、容器内命令和数据库配置。

Steps to reproduce

1. 使用 full 镜像启动 AsterDrive，并确保媒体处理 registry 中 vips_cli 已启用、用途包含 thumbnail:image、扩展列表包含 heic。
2. 为一个 HEIC 文件生成缩略图，确认缓存已经存在。
3. 保留同一数据库和数据卷，将服务切换到同版本 -slim 镜像。
4. 确认容器内 command -v vips 返回空，但管理端仍显示持久化的 vips_cli.enabled = true。
5. 请求 GET /api/v1/public/thumbnail-support，并分别读取旧 HEIC 文件和新上传 HEIC 文件的缩略图。

Expected behavior

需要明确并统一以下三个概念：

1. Configured capability：用户在数据库中配置并启用的处理器及扩展。
2. Runtime availability：当前进程是否能找到并执行 vips / ffmpeg / ffprobe。
3. Effective generation capability：当前实例能否为新文件生成对应派生内容。

讨论倾向：

• 管理端保留并展示用户配置，不因临时切换镜像而静默改写数据库；
• 同时明确展示处理器当前 available / unavailable 状态，而不是只显示 enabled；
• /public/thumbnail-support 的扩展语义需要明确：
  • 若它表示“配置支持范围”，应保留已启用 vips_cli 的扩展，并提供独立的 runtime availability/effective 字段；
  • 若它表示“当前可生成能力”，则继续过滤缺失命令的扩展，但管理端和诊断接口必须说明过滤原因；
• 已有缩略图缓存继续可读；处理器缺失只影响新派生内容生成；
• 新生成失败应返回现有结构化 processor-unavailable 错误，并给出选择 full 镜像或关闭对应处理器的运维提示。

Actual behavior

• Slim 镜像中的 ASTER_BOOTSTRAP_ENABLE_VIPS_CLI=false、ASTER_BOOTSTRAP_ENABLE_FFMPEG_CLI=false 和 ASTER_BOOTSTRAP_ENABLE_FFPROBE_CLI=false 只决定 fresh database 的初始值，不覆盖已有数据库配置。
• public_thumbnail_support 会在 vips_cli / ffmpeg_cli 分支先调用 command_is_available，命令缺失时不合并该处理器的扩展。
• 管理配置仍保留 enabled = true，但公开能力列表已经按运行环境缩减；目前没有足够清晰的状态解释这项差异。
• 旧缓存仍可能正常显示，使问题表现为“旧文件正常、新文件失败”，容易被误判为扩展识别或缓存故障。

Media metadata boundary

/public/media-data-support 与 /public/thumbnail-support 是两份不同契约：

• HEIC 图片元数据可由内置 Rust 解析链处理；
• HEIC 缩略图/图片预览通常依赖可用的 libvips CLI 或 storage-native processor；
• media-data-support 中存在 heic 不代表当前实例能生成 HEIC 缩略图；
• thumbnail-support 中缺少 heic 也不代表无法读取 HEIC 元数据。

两条接口需要独立测试，前端不能把其中一条当成另一条的替代能力表。

Suggested direction

优先保留用户配置，并新增可计算的 effective 状态，而不是在启动时修改数据库：

{
  "kind": "vips_cli",
  "configured_enabled": true,
  "runtime_available": false,
  "effective_enabled": false,
  "unavailable_reason": "command_not_found"
}

公开匿名接口不应暴露本地命令路径；管理员接口或诊断日志可以返回结构化原因。最终是否让 /public/thumbnail-support.extensions 表示 configured 或 effective capability，需要在本 issue 中确定后固定为文档和测试契约。

Acceptance criteria

• full -> slim 和 slim -> full 使用同一数据库的切换行为有回归测试。
• 已启用但命令缺失的 vips_cli / ffmpeg_cli / ffprobe_cli 有明确的 configured、available、effective 状态。
• 管理端能够解释“配置已启用但当前镜像不可用”，且不会静默覆盖用户配置。
• /public/thumbnail-support 对扩展列表的 configured/effective 语义在 API 文档中明确，并由缺失命令测试锁定。
• 已缓存缩略图仍可读取；新派生任务走结构化 processor-unavailable 错误。
• /public/media-data-support 与 /public/thumbnail-support 分别覆盖 HEIC，证明元数据解析与缩略图生成互不替代。
• fresh slim 数据库仍默认关闭外部 CLI processors，已有数据库不会因命令缺失而启动失败。
• Docker 文档说明 full/slim 切换对持久化配置、有效能力和旧缓存的影响。

AsterDrive version

v0.5.0 / current master

Installation method

Docker / Compose (full -> slim runtime variant)

Related issues

• feat(docker): publish slim images without FFmpeg and libvips #513 - slim Docker images without FFmpeg and libvips
• perf(container): audit and minimize the media runtime dependency layer #492 - audit and minimize the media runtime dependency layer

Checklist

• Searched existing issues for duplicates.
• Checked the slim-image implementation and current media capability code.
• Removed deployment hostnames, request identifiers, tokens, credentials, and other private environment details.