Preserve persona.json/conversation_planner.json across outreach-upgrade

[huangruoqi]

Summary

• outreach-upgrade could silently lose a user's persona.json/conversation_planner.json edits: it stashes local changes before git pull --ff-only but only printed a reminder to manually run git stash pop afterward. If upstream had renamed a tracked config to .example (as happened historically for these two files), the stashed edits could end up merged into the .example file or stuck in the stash, leaving the live config path empty — the server then silently falls back to default config with no error.
• Fix: back up the two live config files before the stash/pull dance and restore them unconditionally afterward, independent of how git's stash/rename resolution goes. Also auto-run git stash pop after the pull instead of leaving it to the user to remember.
• Bumped version to 1.0.0.13 with a CHANGELOG entry.

Test plan

• bash -n bin/outreach-upgrade (syntax check)
• Simulated repro in a throwaway repo: old version has conversation_planner.json tracked directly with local edits; upstream renames it to .example and gitignores the live path; ran outreach-upgrade against it — confirmed the user's original content ends up at the live path outreach/config/conversation_planner.json after upgrade, not the default .example content.

[huangruoqi]

Review

Traced the full script flow (bin/outreach-upgrade) against the actual repo state and the scenario described in the PR body. No correctness issues found — clean, well-scoped fix.

What I verified:

• Confirmed outreach/config/{persona,conversation_planner}.json are gitignored/untracked on upstream/main today, so the backup/restore is defense-in-depth for the steady state and the actual safety net for users upgrading from an older install where these were still tracked files (matches the repro in the test plan).
• No trap collision — this is the only trap ... EXIT in the script, so nothing gets clobbered.
• if git stash pop 2>&1; then ... else ... is correctly exempted from set -e (condition of an if), so a pop conflict prints the warning and continues instead of aborting mid-script.
• Restore-after-pop ordering is right: it unconditionally overwrites the live path with the pre-pull backup, so even if stash pop does something weird with a renamed/merged path, the user's original content wins.
• Scope matches the PR description exactly (CHANGELOG, VERSION, bin/outreach-upgrade, pyproject.toml) — no drift.

Pre-existing, not introduced by this diff: if git pull --ff-only fails after a stash was pushed, the script still exit 1s before popping (same as before this change) — recoverable manually, but worth a follow-up if it comes up in practice. Not blocking.

LGTM.