feat(paths): keep user files out of the directory a package manager owns

[donislawdev]

Why

A package manager owns the directory it installs into, and this program was writing the user's own files there.

Read in WinGet's source rather than its documentation: an archive install records the extracted top-level directory as one entry, and an upgrade removes every recorded entry before installing the new ones - remove_all on that directory, with no diffing (PortableInstaller.cpp carries its own TODO: Optimize by applying the difference). Our archive has exactly one top-level directory, so profiles, window state and both CSV exports would be destroyed on every winget upgrade, and a portable package has no script hook a manifest could use to save them.

Chocolatey is the opposite, which is worth stating because the two are usually lumped together: RemoveInstallationFilesUnsafe skips any file absent from the package snapshot, so runtime-written files survive an upgrade. But its package folder grants plain users read and execute only, so a non-elevated run cannot save there at all.

What changed

User files leave the install directory. A frozen build now resolves profiles, window state, both CSV exports and the crash log against %LOCALAPPDATA%\<TOOL_ID>. Running from sources is unchanged, and BEAN_DATA_DIR overrides both for a genuinely portable copy. Files from an earlier version are copied over once, on first start.

Migration copies rather than moves, so rolling back to an older build still finds its files; it only takes a file the target does not have, so a stale copy can never overwrite newer data; it parses nothing on the way, so a corrupt file is copied verbatim and quarantined by the store exactly as before; and it skips a directory carrying a user file's name, which is what Scoop's persist leaves behind.

The location does not probe whether the executable's directory is writable. That was the obvious shape and it is the wrong one: it would make the location depend on elevation - the window elevates itself, --simulate does not - so one install would silently keep two sets of profiles.

The folder follows the Windows account, and the program now says which one it is using. About shows it in its selectable box, --doctor prints it and carries data_dir in its JSON report, and both READMEs explain that elevating on an account without administrator rights uses that administrator's folder, and that an administrator can set BEAN_DATA_DIR system-wide to give every account one shared folder.

Passing the launcher's folder into the elevated copy was measured, considered and rejected: a standard user's AppData is fully controlled by that user, and pointing an elevated process at a directory a plain user controls is the documented precondition for redirecting a privileged write through a directory junction, which needs no privilege to create. That exposure does not exist today, because the elevated copy writes into its own account's folder.

Package sources, as templates. packaging/ holds the Chocolatey and WinGet manifests with {{PLACEHOLDER}} markers, filled by tools/build_packages.py from the one place that owns each value: the version from VERSION.txt, the checksum and the archive name from the release's own SHA256SUMS.txt, the release date from the dated changelog section, URLs from site/site.json, identity and the nested executable path from appinfo. Nothing is published and nothing is wired into release.yml - submitting to a feed stays a human step.

packaging/README.md records the order, including the part that matters most: the first published manifest must point at a release that already keeps user files in %LOCALAPPDATA%, or the upgrade destroys them before the version that migrates them ever runs.

Verified

• python -m pytest tests - 1119 passed, python smoke_gui.py OK, tools/ci_gui_render.py OK on real Tk in both languages.
• Rendered against the published 0.4.0 checksum: winget validate --manifest reports success, choco pack builds the package. That run found a real bug on the way - sha256sum writes <hash> *<file> and the binary-mode star was riding into the installer URL.
• Checked at the source rather than taken from notes: the newest manifest schema is 1.28.0, and ArchiveBinariesDependOnPath adds the directory holding the nested file to PATH - what the implementation does, not what the field's one-line description implies.
• The About line sits on its own line for a measured reason: that box does not wrap and has no horizontal scrollbar, and label plus a realistic frozen path came to 644 px in a 583 px box. Split, the widest line is 413 px.

Guards

New: tests/test_user_data_location.py (11 checks - the location had none at all, because the harness redirects every store to a temp directory) and tests/test_packaging.py (13 checks on files nobody here reviews twice, including one that keeps the package sources tracked).

Eight mutations are registered in tests/test_mutation_registry.py. Two of them survived their first attempt and both were defects in the test: one guard was satisfied by the comment explaining the code it named, the other by a substring another line already contained.

gui/app.py sat exactly on the size ratchet, so the two CSV exports moved to gui/csv_export.py rather than the ceiling moving up. It went down, 1287 to 1202.

One defect was found by CI rather than here, and is fixed in this branch: os.path.relpath
raises on Windows across drives, and the Windows runner keeps the repository on one drive and
the temporary directory on another. Six packaging tests failed there while passing on a machine
where both are on C: and on Linux, where drives do not exist.

Not done here

Nothing is published to either feed and no account exists on them. No package has been installed locally from these manifests - that changes PATH and installs for real, so it waits. The end-to-end case behind the account split (a real standard account going through the UAC credential prompt) is not reproduced: this machine has one user profile.