[Feraris20]

Adds portable mode for #1196. Portable release archives include an empty filee.portable marker, so settings, downloaded engines and logs stay in an adjacent data folder. On macOS, the marker and data folder sit beside Filee.app, outside the signed bundle. The app and CLI both use this location.

If the data folder cannot be written to, Filee shows a clear error and stops instead of falling back to the user profile. Startup and file-manager integration are disabled in portable mode, leaving an installed copy's entries untouched. Installer packages continue to use their normal storage location.

Work folders, temporary files and engine caches keep their existing behavior and locations. Engines selected through “Use my copy…” remain external references. There is no automatic import or migration of existing settings and engines; the documentation explains how to copy them into data manually.

Testing

• Windows: 21 focused core, UI and integration checks passed; 3 Unix-only checks skipped.
• Linux: 26 focused core, UI, integration and installer checks passed.
• Windows ZIP packaging check confirmed an empty marker is included without changing the installer's publish source.
• Formatting and whitespace checks passed.

Real-engine conversions, full release packaging and macOS runtime testing were not performed for the final version.

Closes #1196.

[KnifeLemon]

Thanks a lot for this, it's a careful piece of work: marker detection, the write probe, keeping FILEE_DATA_DIR first, the macOS bundle handling and the updater guard all look right, and the tests are nicely isolated.

Two things block it for now, both about people who already use the portable zip:

1. Shipping the marker by default. After updating, existing portable users start with an empty data folder: settings, presets, history and downloaded engines stay in %APPDATA%/%LOCALAPPDATA%, and first-run setup appears again. Scoop installs the portable zip into a new folder for every version, so there it would happen on every update. Could you either leave the marker out of the archives for now (opt-in by creating the file), or keep it and offer a one-time import on first start when data is empty and the profile has a settings.json?
2. Entries the same copy registered earlier. Until now a portable copy could turn on "Start with Windows" and "Convert with Filee", pointing at its own Filee.exe. With the marker, both switches are off and disabled, SystemIntegrationService.Apply returns early, and --uninstall-cleanup skips them, so those entries can't be removed any more (your A_marked_copy_never_registers_or_removes_installed_integration test pins exactly that). Removing only the entries whose command points at this Filee.exe (once, in portable mode) would solve it.

Smaller points:

• On macOS, a tar.gz extracted in Finder keeps its quarantine flag, and Filee.app then runs from an App Translocation path where the marker isn't visible, so it silently uses the normal profile. Detecting translocation (or at least xattr -dr com.apple.quarantine in INSTALL.txt, as installer/macos/install.sh already does) would help.
• The README has 18 translations, so a long English-only section drifts. Could the details move to a page in docs/, with at most one line in the README?
• Setup /PORTABLE=1 still produces an unmarked copy. Intended?
• install.sh could skip data/ too, in case someone ran ./Filee before installing; otherwise a possibly large engines folder gets copied into the installed copy and never used.
• In PortableStartupFailure, a try/catch around the Avalonia start would avoid a crash when there's no display (SSH, headless).

fa.json and bn-BD.json arrived on main after your branch, so the key test fails for them (startup.portable_unwritable, general.portable_mode). We'll add those two ourselves once the rest is settled, no need to worry about it.

[Feraris20]

Thanks for the review.

1. I’d prefer shipping with the marker and offering migration of existing data and engines, as an earlier local version did. But I’m happy to follow your preference.
2. Migration could clearly explain the cleanup and remove only integration entries belonging to this executable.

I’ll address the remaining points too.

[KnifeLemon]

Thanks @Feraris20, your way sounds good: ship the marker and offer to move the existing data and engines.

A few things would make it safe:

• Ask before moving anything, and say plainly what will be moved and what will be cleaned up afterwards.
• Remove only the integration entries that point to this executable, so an installed copy next to the portable one keeps working.
• If the user says no, or the move fails partway, keep the existing data where it is and leave the app usable.

The other points from the review still apply. Take your time, and pull the branch before your next push in case we've added the Persian and Bengali keys by then.

[Feraris20]

The migration flow now asks before copying and offers separate choices for settings, presets, profiles, history and downloaded engines. Engines stay grouped with their dependencies. Copying shows percentage progress, preserves originals and allows retry after failure. Starting fresh leaves existing data untouched.

Integration cleanup has a separate confirmation and removes only entries belonging to this executable.

The remaining review points are addressed too: Setup’s portable marker, excluding data/ during Linux installation, headless startup errors, macOS quarantine guidance and moving detailed instructions into docs/PORTABLE.md.

Focused checks passed:

• Windows: 41 passed, 2 Unix-only checks skipped.
• Linux: 62 passed, no failures or skips.
• Formatting verification passed.

macOS runtime testing remains unverified.