Add production deployment, photorealistic movement walls, and fix duplicate influence links.

Configure hosting for gallery.mysuperlab.netcraze.pro and LAN access, enhance movement gallery textures with period-appropriate painted materials, dedupe influenced-by API responses via painting_influence_sources, and refresh several painting image files.

Co-authored-by: Cursor <cursoragent@cursor.com>

Documentation/data-and-images.md

@@ -58,9 +58,9 @@ migrate → seed → fetch-artist-bios → expand-catalog → update-influences
 2. For each curated **artist**:
    - Creates **artist periods** and **paintings**.
    - May download portraits and painting images (depending on seed script version).
-3. Writes **painting_influences** edges from curated scholarship references.
+3. Writes **painting_influences** edges from curated scholarship references (mirrored into `painting_influence_sources` when you run `npm run migrate:influence-sources` and `npm run update-influences`).
 
-Those influence edges power **3D hall navigation**: predecessors and successors at each artist’s exit doorway are computed from this table (see `GET /api/artists/:id/navigation` in [API.md](API.md)).
+Those influence edges power **3D hall navigation** and painting detail panels via **`painting_influence_sources`** (see `GET /api/artists/:id/navigation` and `GET /api/paintings/:id` in [API.md](API.md)).
 
 Artists are grouped by movement and century; the seed list targets at most ~100 artists per century.
 
@@ -117,14 +117,24 @@ Renaissance and medieval masters with large museum catalog dumps (e.g. Raphael,
 
 Directed influence links are stored in **`painting_influence_sources`**. Each row connects a painting to a **source** of type `painting`, `artist`, or `movement`, with optional period context (e.g. influence during the work’s creation year).
 
-The legacy **`painting_influences`** table (painting-to-painting only) is still written for hall navigation compatibility and is backfilled into `painting_influence_sources` on migration.
+The legacy **`painting_influences`** table (painting-to-painting only) is still written alongside sources when running `npm run update-influences` — it keeps script compatibility and matches the backfill migration. **The API reads only `painting_influence_sources`**, so each edge appears once in the UI.
 
 Influence data drives:
 
 - **Painting detail** — *Influenced By* (left) and *Influenced* (right) panels: painting thumbnails, artist portraits, or movement colour swatches, plus notes, aspects, period labels, and citations
-- **3D hall exit** — predecessor and successor artists grouped by movement (painting edges only)
+- **3D hall exit** — predecessor and successor artists grouped by movement (from painting and artist sources)
 - **3D gallery lamps** — golden picture light above frames with any influence edge (`has_influence_links` on painting API responses)
 
+### Audit duplicate influence links
+
+Painting-to-painting edges exist in both tables by design. To confirm the database has no stray duplicates and that the API model is clean:
+
+```bash
+npm run audit-influence-duplicates
+```
+
+Reports: edges present in both tables, duplicate rows within either table (should be 0), and legacy-only / sources-only mismatches. If *Influenced* ever shows the same successor twice, restart the server after pulling API fixes — responses must not union legacy and sources tables.
+
 ### One-time migration
 
 ```bash
@@ -310,7 +320,7 @@ These live in `client/public/` (and `client/dist/` after build).
 3. Run `npm run fetch-artist-bios` for the new artist’s biography.
 4. Add entries to `famous-paintings-data.js` and run `npm run expand-catalog` if needed.
 5. Run `npm run fetch-images -- --artist="…"` or rely on preload / on-demand sync.
-6. Add influence rows to `painting_influences` with citation fields where possible.
+6. Add influence rows via `npm run update-influences` / `art-influences-data.js` (writes both `painting_influence_sources` and legacy painting edges).
 
 ## Image fetcher overrides