Refactor FaceAI build process and update Docker configurations to include matcher binary

faceai/README.md

@@ -75,12 +75,11 @@ The checked-in `docker-compose.yml` starts:
 
 The local stack also mounts:
 
-- `../bin/Face_Recognition_Unix` into the processor container as the matcher binary source
 - `../test_pkl` into both the public FaceAI container and the processor container as the shared read-only PKL dataset root
 - `./logs` into both the public FaceAI container and the processor container as the persistent diagnostics directory
 - `../www` into the PHP container so the real bridge files are used
 
-The `processor` service is built from `docker/processor.Dockerfile`, which uses a Debian Trixie-based Node 22 image, applies the current package upgrades available during build, and installs `libxcb1` so the bundled Linux `face_matcher` binary can run locally.
+The `processor` service is built from `docker/processor.Dockerfile` using the repository root as Docker build context. That image copies the checked-in `bin/Face_Recognition_Unix` directory into `/opt/face-recognition` during `docker build`, so the matcher binary is baked into the image instead of being mounted from the host at runtime.
 
 ### Persistent Logs
 
@@ -212,9 +211,23 @@ LIVE_SITE_RUN_UPLOAD_FLOW=1
 When enabled, the live suite also:
 
 - validates that the legacy Face ID handoff URL includes the race storage metadata expected by FaceAI
-- opens the real FaceAI app and asserts that the legacy header stylesheets load from the live legacy site
+- opens the real FaceAI app and asserts that the legacy header stylesheets load from the live legacy site without injecting cross-origin Font Awesome assets
 - confirms the app does not emit the `MISSING_RACE_STORAGE` invalid-race error on launch
-- uploads the supplied portrait image and verifies that search creation succeeds
+- uploads the supplied portrait image, waits for the search to complete, and requires a redirect back to the legacy result page with rendered results
+
+### Processor Troubleshooting
+
+If the processor logs show an error like `spawn /opt/face-recognition/face_matcher ENOENT`, the problem is not the upload flow itself. It means the running processor cannot see the matcher binary at the configured `FACEAI_MATCHER_BINARY` path.
+
+With the current checked-in Dockerfiles, the matcher binary is copied into the image from the repository source tree during `docker build`. The runtime container no longer needs a host bind mount for `/opt/face-recognition`.
+
+Published images now get that binary because the Forgejo container workflow builds from the repository root, which lets `faceai/docker/Dockerfile` copy:
+
+```text
+bin/Face_Recognition_Unix/face_matcher
+```
+
+If a running processor still reports `ENOENT`, the deployed image was built before this change or the build did not include the checked-in matcher directory.
 
 ## Optional Backend And Frontend Dev Loop
 
@@ -320,7 +333,6 @@ services:
       - /mnt/storage/data/faceai/runtime:/data/runtime
       - /mnt/storage/data/faceai/logs:/data/logs
       - /mnt/nas12/nas2/RUS:/data/pkl:ro
-      - /mnt/storage/data/faceai/bin/Face_Recognition_Unix:/opt/face-recognition:ro
     depends_on:
       redis:
         condition: service_healthy
@@ -372,7 +384,7 @@ Processor settings:
 | Variable | Required | Example | Purpose |
 | --- | --- | --- | --- |
 | `FACEAI_PKL_ROOT` | yes | `/data/pkl` | mounted race-to-PKL dataset root |
-| `FACEAI_MATCHER_BINARY` | yes | `/opt/face-recognition/face_matcher` | matcher executable inside the processor container |
+| `FACEAI_MATCHER_BINARY` | yes | `/opt/face-recognition/face_matcher` | matcher executable baked into the image |
 | `FACEAI_WORKER_CONCURRENCY` | optional | `2` | BullMQ worker concurrency |
 | `FACEAI_WORKER_TIMEOUT_MS` | optional | `300000` | matcher timeout in milliseconds |