directory card photos: load from the image endpoint, not inline base64

The webhook no longer sends `Image`, so the card photo comes from its own
endpoint, addressed by the record id — one <img> per card, one request.

- static/expert-image.js: the route AND its query-parameter name in ONE
  constant (id, confirmed by measurement; unverified in the brief), plus an
  optional version token used only when the payload carries one.
- Directory card: <img src="…odoo_experts_image?id=<id>">, width/height
  reserve the 72x72 box, decoding=async, eager for the first row and lazy
  below it; onerror swaps in the SAME monogram a card with no photo shows,
  so a failing image looks exactly like today.
- The static build-time card loses its 185 KB inline base64 photo and shows
  a monogram: it is the no-JavaScript fallback, where there is no onerror to
  fall back with. Page 341,345 -> 158,428 bytes.
- /freelancer-edit/: the photo block is a look, not a field (no file input),
  and the whole-record save sends NO `Image` key at all.

static/expert-image.js

@@ -0,0 +1,48 @@
+/* The freelancer PHOTO — one endpoint, one constant.
+
+   The photo does NOT live in the profile payload any more. It used to ride there as
+   inline base64 under the key `Image`; the webhook no longer sends that key, so the
+   payload is small and the photo is fetched separately, per card, by record id.
+
+   ONE constant holds BOTH halves of the address: the route and the query-parameter
+   name. Changing either is a one-line edit here, and both pages pick it up.
+
+   The parameter name is `id`. It was recorded as UNVERIFIED in the brief (every probe
+   answered "workflow is not registered"), and it is now CONFIRMED by measurement
+   against the live route: `?id=<n>` answers 200 with the photo for that record, while
+   `/4`, `?profile_id=`, `?image_id=` and a missing id all fail. See
+   webmaster/out/2026-11-03-photo-endpoint/REPORT.md.
+
+   The endpoint currently answers `application/json` with `{"Image":"data:image/jpeg;
+   base64,…"}` — a JSON envelope, NOT image bytes — so an <img> cannot decode it and
+   every card falls back to its monogram. That is the measured state, not a guess; the
+   page is built for the shape the brief specifies (an <img> pointed at this route) and
+   starts showing photos the moment the route returns image bytes.
+
+   `versionParam`: appended ONLY when the payload carries a version token, so a
+   year-long immutable cache on the endpoint stays correct — the URL changes when the
+   photo does. Without a token the URL is stable and the endpoint's own headers decide
+   caching (see the report: it sends no Cache-Control and a weak ETag today). */
+window.O4PExpertImage = {
+  endpoint: "https://n8n.odoo4projects.com/webhook/ODOO4projects/odoo_experts_image",
+  idParam: "id",
+  versionParam: "v",
+  // Anything that changes when the photo changes. `updatedAt` used to be in the payload.
+  versionFields: ["updatedAt", "updated_at", "ImageVersion", "image_version"],
+
+  version: function (rec) {
+    if (!rec) return "";
+    for (var i = 0; i < this.versionFields.length; i++) {
+      var v = rec[this.versionFields[i]];
+      if (v !== undefined && v !== null && v !== "") return String(v);
+    }
+    return "";
+  },
+
+  url: function (id, rec) {
+    var u = this.endpoint + "?" + this.idParam + "=" + encodeURIComponent(id);
+    var v = this.version(rec);
+    if (v) u += "&" + this.versionParam + "=" + encodeURIComponent(v);
+    return u;
+  }
+};