Remove Neon-only identity resolver: Motion-web identity resolves from the local daemon DB

[kyra-cpu]

Why

Repo/fleet divergence. The June 2026 runtime change shipped a local daemon conversation store (/daemon/conversation-store/conversations.db + a $CONVERSATION_ID env var), and the fleet's resolvers were re-pointed at it in the June 10–11 rollout — Motion-web identity now resolves locally, no runtime secrets needed. This repo's install path was never updated to match: it still required a runtime database secret at install time. A fresh install should never prompt for a database credential. This PR brings the repo in line with the fleet.

What changed

add-roles-permissions v3.1.5 → v3.3.0 (v3.2.0 is claimed by #115 — attribution removal; no rebase needed, the diffs don't overlap on the resolver)

• SKILL.md Phase 5 Step 4: the embedded Neon motion-whoami.sh + motion-whoami-neon.py helper are replaced with a single daemon-DB resolver. A leftover-helper cleanup instruction is included for upgrades.
• Phase 1 Look-around 6: the runtime-secret hard-stop is gone. The check is now "daemon DB exists + sqlite3 available" — both on every current VM by default — and a miss warns instead of blocking (outdated image; Motion-web users resolve as unknown until the runtime is updated).
• Fail-loud semantics kept (6/2 decision): resolver failure → non-zero exit with error JSON on stderr → permissions layer treats unknown identity as no-writes.
• README.md: prerequisites drop the runtime secret, add sqlite3; identity-resolution description updated ("local daemon conversation store, no runtime secrets required").
• use-case.json / install-config.json: no secret declarations existed; only the version bump.

team-member-memory v3.1.0 → v3.2.0

• motion-whoami.sh: same resolver swap. Softer failure semantics kept (6/2 decision): any lookup failure returns status: "unresolved" with exit 0, and the behavior-snippet asks the user where to save instead of guessing a handle.
• motion-whoami-neon.py deleted; removed from the install-config.json install list.
• behavior-snippet.md + README.md updated to describe the daemon-DB path. Home bases stay at /agent/brain/identity/people/ (the v3.1.0 path migration is respected).
• slack-whoami.sh untouched — it never used Neon.

Provenance of the resolver

The script was not reconstructed from memory. The resolver deployed across the fleet in the June 10–11 rollout (compatibility variant) was reproduced byte-for-byte from the rollout records and verified against the recorded hash:

sha256(reconstructed) = 946bfa2a043944075ba0ad415faa35a28d668cca07131fbeea551244e5f85d01  ✓ matches the fleet rollout records

The version shipped here differs from that byte-proven script in exactly three ways (verified by diff — all resolution logic is identical):

1. Header comment text.
2. Map file: organization-map.json / RUNNETH_ORG_MAP (repo convention since add-roles-permissions: organization-map rename + Neon-only motion-whoami #98) instead of the fleet's workspace-map.json / RUNNETH_WORKSPACE_MAP. The use case scaffolds organization-map.json, and the resolver must read the file the use case writes.
3. Home bases: /agent/brain/team/ (permissions, per v3.1.3 rename) and /agent/brain/identity/people/ (team-member-memory, per its v3.1.0 migration) instead of the fleet's /agent/brain/members/.

The compat behavior is included: reads .motionUserEmails with legacy .motionEmails fallback, and keeps both maps in sync on provision — strictly safer for upgrades from older installs.

Local verification done

• bash -n passes on both resolvers (the SKILL.md-embedded one was extracted and checked).
• Functional test against a synthetic conversations.db: resolved via motionUserEmails ✓, resolved via legacy motionEmails ✓, auto-provision writes both maps + scaffolds home base ✓, missing CONVERSATION_ID → error JSON + exit 1 (permissions) / unresolved + exit 0 (tmm) ✓, missing daemon DB → fail-loud (permissions) / unresolved (tmm) ✓.
• Grep: no runtime-secret references, no agent_conversation, no secret run, no /agent/.runtime/conversations.db outside changelog history; daemon/conversation-store + CONVERSATION_ID present in all the right places.
• All JSON files validate.

Still to do before merge (needs VM access)

1. Fresh install on the internal test sandbox — must complete without any secret prompt.
2. New-conversation identity resolution on the test sandbox (the failure mode the Neon path was originally built to fix).
3. Known risks from the fleet rollout to spot-check: $CONVERSATION_ID may not be set in all invocation contexts (jobs/routines); daemon DB may not exist on older images; sqlite3 -readonly -json needs a recent sqlite3. team-member-memory degrades gracefully on all three; add-roles-permissions fails loud by design.
4. One inherited quirk, identical to the byte-proven fleet script: when the conversation ID has no row, the script exits 1 at the parse step without printing the error JSON (set -e kills it first). Still fail-loud; kept as-is to match fleet behavior.

Out of scope

• Re-pointing the remaining fleet VMs that still run the previous resolver (tracked internally), and removing their runtime secret once re-pointed.

Refs: PDEC-7817

🤖 Generated with Claude Code