release(v1.11.1): pi 1.2.0; CI builds the pinned pi-obsmem SHA

- pi 1.1.0 -> 1.2.0, audited on tor-ms22 from an isolated prefix: none of
  the four breaking changes reaches the image (3 before_agent_start
  handlers checked, no triggerTurn user, pi-studio themes load); agent-core
  dist byte-identical; turn cap N=19 honoured; atelier paints in both
  renderers; obsmem /om:* registered; real-config startup clean.
- resolve-versions reads ARG PI_OBSMEM_REF from Dockerfile.variant instead
  of resolving obsmem master (which overrode the pin as --build-arg),
  requires a 40-char SHA, and warns when master moves past the pin. Block
  tested in isolation: real pin, short/branch/missing pin, older pin,
  GitHub unreachable.
- CHANGELOG: Unreleased -> v1.11.1 — 2026-10-14. README pin table,
  BASE_REBUILD_DATE marker (base rebuilds anyway), stale VENDORED.md pointer.

rootfs/usr/local/share/pi-devbox/skills/VENDORED.md

@@ -61,7 +61,7 @@ its skill file needed baking.
   `docker build` records the same thing CI does.
 
   Verifying "is this snapshot current?" is **not** a CI job and was deliberately
-  not made one — see the Unreleased CHANGELOG entry for why (private repo;
+  not made one — see the v1.8.8 CHANGELOG entry for why (private repo;
   another repo's branch must not be able to fail this build; and the artefact it
   would guard is read by no host on this fleet). The check belongs where the
   skillset actually is: `vendor-mempalace-skill.sh --check` for a maintainer,