feat(monitor-frontend): add FaceAI Audit Monitor application with Vue.js and Vite setup

- Created App.vue for the main application interface with localization support.
- Added main.js to bootstrap the Vue application.
- Introduced styles.css for application styling.
- Configured Vite for development and proxying API requests.
- Updated docker-compose files to include the new monitor service.
- Added Dockerfile for building the monitor frontend.
- Configured Nginx for serving the frontend and proxying API requests.
- Updated package.json and package-lock.json to include monitor-frontend workspace.
- Added initial SQLite database for audit monitoring.

faceai/README.md

@@ -5,6 +5,7 @@ This folder scaffolds the new FaceAI app described in the integration plan.
 It includes:
 
 - a Vue frontend for the FaceAI upload and polling flow
+- a separate Vue monitor frontend for querying the FaceAI audit database
 - a Node/Express backend for session exchange, queueing, and return handoff
 - a dedicated processor runner that consumes matcher jobs from Redis and executes `face_matcher`
 - a local Dockerized Tomcat/JSP stack so the launch and return flow can be tested against the real legacy race pages under `www/`
@@ -16,6 +17,7 @@ faceai/
   apps/
     backend/
     frontend/
+    monitor-frontend/
     processor/
   docker/
     Dockerfile
@@ -26,11 +28,13 @@ faceai/
 The production-oriented application topology is still three services:
 
 - `faceai`: public HTTP service on port `3001`, serving the built Vue app and the authenticated API
+- `faceai-monitor`: read-only audit monitor on port `3002`, serving a lightweight Vue dashboard backed by the audit API
 - `processor`: background matcher runner consuming BullMQ jobs from Redis and executing the Linux `face_matcher` binary
 - `redis`: short-lived queue and search-state store
 
 The checked-in development override now expands that into the full local integration stack:
 
+- `faceai-monitor`: local audit dashboard that proxies read-only audit-monitor API calls to the backend
 - `tomcat-www`: local Tomcat runtime serving the real legacy JSP race pages from `www/`
 - `mysql`: local legacy database used by the Tomcat stack
 - `maildump`: local SMTP sink and viewer for the Tomcat stack
@@ -81,6 +85,7 @@ The checked-in Compose setup now uses:
 The local development stack started by the command above combines the base file and the override and starts:
 
 - FaceAI public site on `http://localhost:3001`
+- FaceAI monitor on `http://localhost:3002`
 - processor runner on the internal Compose network
 - Redis on the internal Compose network
 - Tomcat serving the real local legacy site on `http://localhost:8080`
@@ -93,6 +98,8 @@ The local stack also mounts:
 - `./logs` into both the public FaceAI container and the processor container as the persistent diagnostics directory
 - `../www` into the Tomcat build/runtime inputs so the real legacy JSP pages and assets are used
 
+The separate monitor container does not mount the SQLite database directly. Instead it serves a static Vue app and proxies read-only requests under `/api/audit-monitor/*` to the existing backend service, which remains the only process that opens the audit database.
+
 The `processor` service is built from `docker/processor.Dockerfile` using the repository root as Docker build context. That image copies only the checked-in Unix `face_matcher` into the image, so the matcher is baked into the processor runtime without bringing along the other Unix or Windows binaries.
 
 ### Persistent Logs
@@ -131,6 +138,19 @@ Open:
 http://localhost:8080/Foto2.abl?id_gara=1018557&pageRow=96&pageNumber=1
 ```
 
+For audit visibility during local runs, also open:
+
+```text
+http://localhost:3002
+```
+
+The monitor shows:
+
+- lifetime and recent-window search totals from the SQLite audit log
+- the latest searches with filter-by-status and free-text lookup for race, user, result, error code, selfie name, or search id
+- per-search event timelines and stored match snapshots
+- recent events and a recent top-race breakdown
+
 That is the real local Tomcat race page. It loads the original race-page JavaScript from `www/_js/rus-ecom-240621.js`, lets the script replace the visible `tipoPuntoFoto` selector with the new `Face ID` button, and launches the backend handoff endpoint configured through the JSP page.
 
 ### Expected Local Flow
@@ -473,6 +493,16 @@ FACEAI_FEATURE_ENABLED=1
 
 The checked-in `docker-compose.override.yml` sets that on the local `tomcat-www` service so the race page can launch the FaceAI handoff flow locally.
 
+### Audit Monitor API
+
+The monitor frontend uses these read-only backend routes:
+
+- `GET /api/audit-monitor/summary`
+- `GET /api/audit-monitor/searches?status=...&query=...&limit=...`
+- `GET /api/audit-monitor/searches/<searchId>`
+
+They read the same SQLite audit database already configured through `FACEAI_AUDIT_DB_PATH`. The monitor container proxies those requests to `faceai`, so no browser-side direct SQLite access is involved.
+
 ## Notes
 
 - Search orchestration now uses Redis and a dedicated processor worker.