fix(profiles): a profile's load-time migration saves to its own file (#316)

[GabrielDumbrava]

Closes #316

Problem

load_settings_in(id) reads any profile's settings, applies its load-time migrations, and when one changed something persisted with save_settings_inner, which is the ROOT writer.
Loading a non-root profile that needed a migration therefore wrote that profile's settings over the root profile's settings.json: the root's accounts, default, adopted account, default tasks path and every other root-only setting went with it.
The non-root file never received the migration, so it needed it again on the next load, and the root file was overwritten again every time that window loaded its settings.

Seen as accounts that could not be kept: added in the root profile, gone after the next action in the other profile's window.
The account carries in agents_save (0cdfb58) and settings_save (#309) never saw it, because this path goes around both.

Fix

One line: the migration saves to the profile it was read from, save_settings_in(id, &s).
The two other save_settings_inner calls (stamp_schema_version, migrate_cli_enabled_default) are startup migrations of the root profile and are unchanged.

docs/profiles.md records the trap: inside a per-profile path, *_inner means the root profile, not "this profile".

Tests

• New Rust test a_profile_that_needs_a_migration_writes_its_own_file_not_the_roots: a root profile with accounts and its own tasks path, and a second profile whose file carries the legacy worktree_symlink_paths default. Loading the second profile leaves the root file byte-for-byte unchanged and writes the migration into the second profile's own file. Control: with save_settings_inner the test fails; with the fix it passes.
• cargo test: 1073 passed.

Manual verification

Not manually verified in the app: I opened this without a hand test.
The failure itself was observed on the real install before the fix: watching the root settings.json showed it rewritten on actions in the second profile's window, and its default_tasks_path had become the second profile's.

Settings already overwritten are not restored by this and have to be set again.

🤖 Generated with Claude Code

[simion]

Merged, thanks @GabrielDumbrava. Clean one-line fix, verified it writes to the profile's own file and leaves the root migration writers untouched.