fix(pulse): resolve pai-root-relative targetFile in applyProposalEdit (memory-proposal apply fails)

[anikinsasha]

Problem

Applying a memory-system proposal from Telegram (yes #<id> / edit #<id>) always fails with:

❌ Couldn't apply: target file missing: LIFEOS/USER/CONFIG/OPERATIONAL_RULES.md

…even though the target file exists.

Root cause

applyProposalEdit(targetFile, editText) receives a pai-root-relative target_file (e.g. LIFEOS/USER/CONFIG/OPERATIONAL_RULES.md, as stored on the proposal) and passes it straight to existsSync / readFileSync / renameSync, which resolve relative paths against process.cwd(). The Telegram bot runs from LIFEOS/PULSE (its launchd WorkingDirectory), so the path resolves to a nonexistent nested location and the existence check fails. This breaks proposal ratification for any standard install.

Fix

Resolve targetFile against ~/.claude when it isn't already absolute — matching the HOME/.claude convention this file already uses a few lines up (for OBS_DIR). One resolution line plus an isAbsolute import; all file ops use the resolved path.

Repro

1. Let the memory loop surface an operational-rule proposal to Telegram.
2. Reply yes #<id>.
3. Before: target file missing. After: the rule is appended to OPERATIONAL_RULES.md under ## Memory-System Proposals.

Verified

Applied locally and called applyProposalEdit("LIFEOS/USER/CONFIG/OPERATIONAL_RULES.md", …) → { ok: true }; the rule landed correctly under the section header.

[danielmiessler]

Ported to the private source tree with credit. Thank you. One adaptation: the Telegram surfacing channel was removed on 2026-07-15, so telegram-proposals.ts no longer exists; your fix now lives in its successor LIFEOS/PULSE/lib/memory-proposals.ts, where applyProposalEdit had the identical CWD-relative bug. Same resolution logic (isAbsolute check, resolve against ~/.claude, temp-file rename against the resolved path), verified working from a foreign CWD.

Closing instead of merging because the public repo is a generated artifact; a direct merge here would be silently overwritten at the next release. Your fix ships in that release, credited in the commit.