[FEATURE] Support configuration storage outside MSIX AppData

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

I'm using the Claude Desktop app in a Windows Sandbox session. It's the only reasonable tool I can think of to sandbox Claude on Windows and which allows development of actual Windows software, while also avoiding being prompted every second or two for permission to run a new tool.

I have the scripted the creation of the WSB session, i.e. the WSB XML is provided directly to `wsb start --config "$HERE"`. The Claude Desktop app is installed among other tools like Git via a WSB `LogonCommand` script, and I have a number of `MappedFolder` entries in my WSB to facilitate this. One of these is the Code config/session directory, mapping a directory on my host to `C:\Users\WDAGUtilityAccount\.claude` to facilitate persistence of session data across sandboxes, which are completely ephemeral. This works fine for the Code CLI, but is insufficient for the Desktop app, which, as I understand, stores an index of the Code sessions in its isolated MSIX storage. When I start the desktop app, the side bar is empty, and attempting to use the `/resume` tool lists nothing, even after pre-approving the working directory they're linked to. After fumbling around trying to find where this data is stored, I can see the files are written to the MSIX packages storage. A Claude session was enough to determine some characteristic of this and try a few workarounds.

This is where the problems begin: can't provide this directory, `%APPDATA%\Claude\`, via a persistent WSB mapping from my host machine, because the the MSIX mechanism seems to mount over the top of it. I can't copy files into it after installing, because that doesn't work (my script tells me the directory doesn't exist, and even if I could I'd need to have some hook for copying them back to persistent storage when the sandbox closes. This could be manual step, except nothing would call that when Windows Update is what's responsible for the restarts most of the time.

It seems that little about the Desktop app _can_ work smoothly in this described setup: as best as I can make out the OAuth token for login is stored in the same place, but is DPAPI encrypted which means based on the current user's key which is... recreated for every sandbox session. So even if I could persist the entire app data directory this would still be broken.

### Proposed Solution

Ideally I would just tell the Desktop app where to read and write its configuration and session store from another location. Or even better, it would just be able to sources the list of sessions directly from the CLI app instead of being dependent on a secondary data store. This could be achieved using an environment variable as is common with the CLI tool, like `CLAUDE_CONFIG_DIR`

### Alternative Solutions

I'm presently trying not to close my WSB session at all because of the risk of losing access to my session. If I have to restart--and this is Windows so MS doesn't give me a choice--I'm presently asking a new Claude session every time to restore the index from the session files on disk. It's a crapshoot. It mostly works, but it tedious and exceedingly time consuming, not to mention risky. Claude has created various script to automate the restore on start, but nothing is installed and trying to write the files before the app is installed doesn't work, and writing them after it's running is just as fruitless.

### Priority

High - Significant impact on productivity

### Feature Category

Configuration and settings

### Use Case Example

Everyday use. Being able to use a sandboxing tool on Windows to stop an LLM from destroying my system is a basic necessity.

### Additional Context

_No response_