[Feature]: Choose where extracted stems are stored #354

Problem

Reported by a user:

the folder created by the app is automatically created in my Documents folder, which is backed up to my cloud. So I just discovered that my cloud is suddenly 2.5GB bigger.

I couldn't find the option to change the location of files saved, so could you add that please?

The desktop app puts extracted stems in ~/Documents/StemDeck/jobs, chosen in documents_dir_for_jobs and handed to the backend as STEMDECK_JOBS_DIR. Documents is the right default -- the library is the user's work, it should be visible in Finder and survive a reinstall -- but on macOS and Windows it is also a folder most people have syncing to iCloud or OneDrive.

Stems are six WAVs plus a video track per song, roughly 160 MB. A modest library is tens of gigabytes of cloud storage the user never asked to spend, and there is currently no way to change it short of editing the environment by hand.

What it should do

A setting under Settings -> General that picks where extracted stems live.

• Shows the current path, with a native folder picker on desktop.
• Validates the choice before accepting it: it has to exist, be writable, and not be inside the app bundle or the previous location.
• Moves the existing stems to the new location, so the point of the exercise is actually achieved. The registry lives in that folder, so leaving it behind would also make the library come back empty.
• Refuses while a job is running -- moving files out from under a separation would corrupt it.

The library index (user-data.json) stays in Documents. It is a few kilobytes and nothing to do with the complaint.

Notes

JOBS_DIR is bound at import time in several modules, so a change needs a restart to take effect. The desktop launcher reads the preference before it spawns the backend; settings.json already lives in a fixed app-data location it can read.

Same-filesystem moves are a rename and instant. Across filesystems it is a copy, which for tens of gigabytes needs to report progress and must not leave the library half-moved if it fails.