feat(cli): thread Config through the export path

[ecalifornica]

cmd_export::run (along with its forwarders in cmd_project and cmd_incept) takes &Config. cmd_resume::project_into_harness takes &ProjectionConfig.

ProjectionConfig is the subset of Config that builds a provider manager: the harness store roots ($HOME with the $USERPROFILE fallback, $XDG_DATA_HOME, $COPILOT_HOME, $APPDATA). Config::projection builds it. The providers::*_convo factories take &ProjectionConfig; the other command modules call them with config.projection().

Each of the 9 export helpers that writes into a harness's on-disk layout takes &ProjectionConfig and builds its PathResolver from providers::<harness>_convo(config).

cmd_resume::run_with_strategy loads a Config at its call site because resume is threaded by its own PR.

The cmd_export unit tests inject a Config instead of setting $HOME, and drop the TEST_ENV_LOCK guard.

Behavior change: on Windows with $HOME unset, the pi export paths resolve %USERPROFILE%\.pi\agent\sessions, matching the import and sync paths.

Part of #184.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

🔍 Preview deployed: https://8e66b458.toolpath.pages.dev

[akesling]

Should we have some projection config type that we build from our general config so we aren't passing all the config info everywhere? This would make clear what is needed by the lower layer.