feat(ai): add a Reset AI Environment admin feature for the upgrade gap (#459)

Uninstalling a bundle only deletes its downloaded model weights, never the
shared venv's site-packages, so self-hosters who already hit an AI bundle
conflict (e.g. the scipy ABI strand) have no clean self-service path via
uninstall+reinstall: reinstalling just overlays corrected files on top of
stale ones. Adds POST /api/v1/admin/features/reset, which wipes
/data/ai/{venv,models,pip-cache}, resets installed.json, and reseeds a real
working venv from the image's baked /opt/venv (extracted docker/reseed-ai-venv.sh,
now shared with entrypoint.sh's existing base-venv-upgrade bootstrap instead
of duplicating that logic) -- leaving an empty venv directory here would
make the very next install fail with "spawn .../python3 ENOENT", caught by
testing this live rather than assuming it. Ships with a matching Settings UI
section (inline confirm, same pattern as per-bundle uninstall) and strings
across all 21 locales.

Verified against a real snapotter/snapotter:1.17.2 image migrated to 2.0.0,
with real multi-GB bundles installed (background-removal + OCR): confirmed
the migrated instance's inherited python3.11 venv (2.0.0 itself uses 3.12)
still imports the fixed scipy/numpy/paddleocr correctly, then reset + real
reinstall + actual tool execution (remove-background, verified output image)
all worked end-to-end.

docker/entrypoint.sh

@@ -119,11 +119,7 @@ if [ -d "/opt/venv" ]; then
   fi
 
   if [ "$NEED_BOOTSTRAP" = true ]; then
-    mkdir -p /data/ai/models /data/ai/pip-cache
-    rm -rf "$AI_VENV"
-    cp -r /opt/venv "$AI_VENV_TMP"
-    mv "$AI_VENV_TMP" "$AI_VENV"
-    rewrite_venv_paths "$AI_VENV" "/opt/venv" "$AI_VENV"
+    /usr/local/bin/reseed-ai-venv.sh
     # Reset installed-bundle state: their packages lived in the old venv.
     # Models in /data/ai/models survive, so reinstalling a bundle only
     # reruns pip (model downloads are idempotent and skip existing files).