curate Phase 1: resolve MEM_DIR via --project-link-state, not a hand-rolled sed slug (breaks on Windows)

[s-annam]

Problem

skills/okfmem-curate/SKILL.md Phase 1 derives the memory dir by hand-rolling the project slug:

# skills/okfmem-curate/SKILL.md:54-56
# project slug = absolute cwd with / replaced by -
SLUG=$(pwd -P | sed 's|/|-|g')
MEM_DIR="$HOME/.claude/projects/$SLUG/memory"

This reimplements memory_init.encode_root — badly — and is wrong in two ways.

1. It eats the drive colon on Windows

encode_root encodes both the separator and the drive colon:
C:\Users\you\okfmem → C--Users-you-okfmem (the : becomes the second dash). The sed
above replaces only /, so on a Windows checkout it produces a slug that does not match any
directory under ~/.claude/projects/. Phase 1's own guard then fires — "If $MEM_DIR doesn't
exist, tell the user and stop" — so /okfmem-curate cannot run at all on Windows unless
the user passes an explicit path argument every time. Silent-ish (it reports a missing dir),
but the reported cause is wrong: the dir exists, the slug is.

This is the same drive-colon-shape footgun documented across the repo's Windows work
(#14/#16/#17, #41, #42) — a hand-rolled separator swap standing in for encode_root.

2. It ignores project renames

encode_root is only half the resolution. The registry (~/okfmem-store/registry.json) maps a
repo root to its store project name, which honours renames and per-project overrides. A raw
cwd-to-slug transform can't see any of that, so a renamed project resolves to a stale or
missing directory even on POSIX, where the sed is otherwise correct.

Fix

okfmem init --project-link-state already exists (shipped #48) as the shared read-only probe
for exactly this question. It returns one of linked <name> / unlinked <name> /
not-a-repo / no-claude, resolves the name through the registry, and never re-derives the
encoded path in shell. skills/okfmem-save/SKILL.md Step 1 already uses it — this is a
straight port of that block, and it kills the sed for the same stated reason.

Replace Phase 1's derivation with:

# Ask the engine, rather than re-deriving the encoded path: `encode_root` also
# encodes the drive colon on Windows, so a hand-rolled sed resolves to the wrong dir.
LINK_STATE="$(okfmem init --project-link-state)"   # linked <name> | unlinked <name> | not-a-repo | no-claude
STORE="${OKFMEM_STORE:-$HOME/okfmem-store}"
MEM_DIR="$STORE/projects/$(echo "$LINK_STATE" | awk '{print $2}')"

and give each non-linked state a specific message rather than the generic
"$MEM_DIR doesn't exist":

State	What Phase 1 should say
linked <name>	proceed
unlinked <name>	this repo has no memory link — run okfmem init from the repo root, then re-run
not-a-repo	cd to the project root first
no-claude	the harness isn't installed; nothing to curate

Keep the existing behaviour that an explicit path argument overrides everything — that is
the escape hatch that made this bug survivable, and audit <path> depends on it.

Phase 1's symlink-detection step (readlink "$MEM_DIR") is unaffected and stays as-is.

Acceptance criteria

• skills/okfmem-curate/SKILL.md Phase 1 no longer contains pwd -P | sed; it resolves
  MEM_DIR via okfmem init --project-link-state.
• The resolved path is correct on Windows (drive colon encoded) — verified against
  encode_root, not against a hand-typed expectation.
• A renamed project resolves through the registry to its current store project name.
• Each of the four probe states has its own message; unlinked names okfmem init as the
  remedy rather than reporting a missing directory.
• An explicit path argument still overrides the probe (/okfmem-curate audit <path> works
  outside a repo).
• python3 scripts/check-leaks.py exits 0 — the snippet uses ~/okfmem-store /
  $OKFMEM_STORE, never a real home path.

Notes for the implementer

• This is a skill-text change, not engine code — no new Python, no new subcommand. The probe
  it calls already ships.
• Grep for other hand-rolled slug derivations while you're here. okfmem-save was already
  ported on feat(init): seed store project on init + nag unwired repos on four surfaces #48; curate is the known remaining one, but a third would be the same bug.
• Phases 4 and 5 remain gated on explicit user approval (CLAUDE.md confirmation discipline);
  nothing in this change touches that.

[s-annam]

Implementation Complete — 204cba5

Landed via #59.

Acceptance Criteria

• No pwd -P | sed in Phase 1 — MEM_DIR resolves via okfmem init --project-link-state.
• Correct on Windows — the path comes from the engine, which uses encode_root (drive colon and all); nothing is hand-derived in shell, so there is no hand-typed expectation left to be wrong.
• Renames resolve — the probe reads the registry rather than transforming the cwd.
• Each probe state has its own message — unlinked names okfmem init as the remedy instead of reporting a missing directory. A fifth row was added for "engine unreachable", which the issue's four-state table did not cover.
• Explicit path still overrides the probe — the audit <path> escape hatch is unchanged.
• python3 scripts/check-leaks.py exits 0 — only ~/okfmem, ~/okfmem-store, $OKFMEM_STORE placeholders.

Additional Changes

Two defects the fix itself introduced, both caught by pre-PR adversarial review and fixed in the same PR:

• The suggested snippet collapsed MEM_DIR to the store's projects root. awk '{print $2}' yields empty for not-a-repo, no-claude, and for okfmem off PATH (a configuration install.sh supports), so MEM_DIR became $STORE/projects/ — a real directory that passes any -d guard. Phases 2–3 would have reported on the wrong tree and Phase 4 would have asked for deletion approval derived from it. Replaced with read -r STATE NAME (${LINK_STATE#* } returns a single-word value unchanged, so not-a-repo would have become the project name), two separate probe assignments so an error string cannot concatenate onto a valid state, and a dir assigned only on the linked branch. Every downstream call site now carries ${VAR:?...} so an unresolved dir refuses instead of failing open.
• The same block in skills/okfmem-save/SKILL.md had the identical defect with a larger blast radius — that skill writes, so STATE.md and the session's pages would have landed in the projects root where nothing auto-loads them. Fixed there too (a deliberate one-file scope expansion beyond this issue).
• Collateral from that fix: MEM_DIR is now the symlink's target, so the unchanged readlink "$MEM_DIR" git-recoverability probe printed nothing and exited 1 on every correctly linked store — curate would have reported deletions as unrecoverable 100% of the time on the happy path, inside Phase 4's hard approval gate. Replaced with git -C "$MEM_DIR" rev-parse --show-toplevel, which tests the property rather than a proxy and also covers the explicit-path escape hatch readlink never handled.
• Stale line noted, not silently changed: SKILL.md:25 still describes the target as ~/.claude/projects/<project-slug>/memory/ — the same directory via the symlink, so not wrong, but pre-change in shape.

Verification

The shipped Phase 1 fenced blocks were extracted programmatically from the markdown and executed under zsh 5.9 and bash 3.2 across linked / unlinked / not-a-repo / no-claude / off-PATH / engine-unreachable / bare linked with no name / a project name containing a space.