changelog: file the vendored-skill shadowing bug for v1.8.5

~/.agents/skills is asymmetric: the three pi-devbox-specific skills resolve to
the baked copies while all others resolve to the live skillset clone. Root cause
is ordering in entrypoint-user.sh -- baked links are created early (line 65) with
a create-only-when-absent guard, and the skillset deploy runs last (line 387) and
leaves them alone as foreign links. The comment at line 61 states the intent as
protecting the skillset skill from being clobbered, but the effect is the
reverse.

Cost measured on two hosts: a pushed edit to the mempalace skill (live md5
129bcc4752) was invisible to both containers, which kept loading the baked copy
(md5 5236024fef). Editing those three skills appears to work and silently does
nothing until a rebuild.

Filed as a known issue with a proposed fix rather than fixed here: changing
symlink precedence is image behaviour and wants its own review plus a smoke
assertion, and the early-link ordering exists to close a readiness race that
must not regress.

CHANGELOG.md

@@ -15,6 +15,39 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 Docs only so far, but one of the two files ships **inside** the image.
 
+### Known issue (proposed for v1.8.5, not yet fixed)
+
+- **Vendored skills silently shadow their live skillset counterparts — an
+  ordering bug, and the code comment claims the opposite.** `~/.agents/skills`
+  is *asymmetric*: `mempalace`, `pi-devbox-environment` and `pi-extensions`
+  resolve to the baked `/usr/local/share/pi-devbox/skills/…`, while every other
+  skill resolves to the live `/workspace/skillset/skills/…`. Root cause is
+  precedence-by-ordering in `entrypoint-user.sh`: the baked links are created at
+  **line 65** (deliberately early, to close a smoke-test readiness race) with
+  `[ ! -e … ]` so they are "created only when absent", and the skillset deploy
+  runs **last** at line 387, where it classifies the existing links as
+  foreign and leaves them alone. The comment at line 61 states the goal as "a
+  same-named skillset skill … is never clobbered" — but with baked-first plus
+  create-when-absent, the *skillset* skill is precisely the one that loses.
+
+  Observed cost, on two hosts independently: an edit to
+  `skillset/skills/mempalace/SKILL.md` (adding a drawer-attribution rule) was
+  pushed and present in the live clone (`md5 129bcc4752`), yet both the
+  EMB-7KJ4VR4G and tor-ms22 containers kept loading the baked copy
+  (`md5 5236024fef`) with zero occurrences of the new rule. The tor-ms22 agent
+  had to fetch the rule from the Gitea API to read it at all. Editing a
+  skillset skill therefore *appears* to work and silently does nothing until an
+  image rebuild — for exactly the three skills most likely to be iterated on,
+  since they are the pi-devbox-specific ones.
+
+  Proposed fix (surgical, keeps the race fix): leave the early baked links as
+  the fallback, and let the skillset deploy at line 387 **replace** links that
+  point into `/usr/local/share/pi-devbox/skills/` when it ships a skill of the
+  same name — i.e. baked = default, live clone = preferred when present. User
+  overrides (a real directory, or a symlink pointing elsewhere) must still win
+  over both. Verify after the change with
+  `readlink -f ~/.agents/skills/mempalace`, not by reading the entrypoint.
+
 ### Changed
 
 - **`pi-devbox-environment` skill — new §2 subsection "A negative result is