fix: build image libraries for baseline VPS CPUs

Replace the SIMD-dependent WebAssembly fallback with source-built libvips and Sharp. Pin the libvips archive checksum, use baseline x86-64 compiler flags, retain the native binding and runtime libraries, and check JPEG/PNG/WebP processing before compilation and in the runtime image.

Lint, type checking, and content/security tests passed. Full Docker verification was stopped at the user request; production build and baseline CPU runtime verification remain pending.

SELF_HOSTING.md

@@ -57,10 +57,12 @@ Drizzle Kit, npm installs, or a compiler at runtime. Startup applies the committ
 SQL migrations and seeds samples only when the database is empty. `/api/health`
 checks database readiness without rendering the portfolio.
 
-Sharp uses native image processing where supported and includes a WebAssembly
-fallback for servers without the required x86-64 CPU features. The fallback
-preserves uploads and image optimization, but can use more CPU time. Keep
-`@img/sharp-wasm32` at the same version as `sharp` when upgrading.
+The Docker build compiles libvips and Sharp from source for baseline CPUs. This
+supports VPS hosts that lack the features required by Sharp's prebuilt native
+and WebAssembly binaries. The first build takes longer; Docker caches the image
+libraries for later application changes. Image processing is checked before
+Next.js compilation and again in the final runtime image. When upgrading Sharp,
+keep the libvips source version in the Dockerfile at or above Sharp's minimum.
 
 Use one application instance with a local filesystem. Do not mount the SQLite
 database over NFS/SMB, use an ephemeral serverless disk, or run multiple replicas