Keep finished tracks unless the user asks otherwise

[thcp]

Closes #459
Closes #462
Closes #463

The report

A user restored a library of four completed jobs, started the 0.15.1 backend against it, and two of them were gone: from data/jobs/ and from registry.json. They reproduced it twice, kept read-only backups, and rolled back to 0.13.0.

I reproduced it on the packaged 0.15.2 backend using their own job IDs:

	before	after
without STEMDECK_DESKTOP=1	all four	d81f3ab304ab, e0ed2aafc483
with STEMDECK_DESKTOP=1	all four	all four

Same survivors they saw. The selection is age, not source type: sweep_old_jobs deletes terminal jobs past a 24 hour TTL, and it runs seconds after startup.

It was never a 0.15.1 regression. app/pipeline/collect.py has no commits between v0.13.0 and v0.15.1 and the gate in app/main.py was byte identical. Three separate problems stacked up to produce it.

1. Deletion was the default (#459)

Safety depended on an environment variable being present:

def _sweep_disabled() -> bool:
    return (
        os.environ.get("STEMDECK_DESKTOP") == "1"
        or os.environ.get("STEMDECK_PERSIST_LIBRARY") == "1"
    )

Every documented way of launching StemDeck sets one of those. The shell sets STEMDECK_DESKTOP=1, run.sh defaults STEMDECK_PERSIST_LIBRARY=1, the Unraid template ships it as 1. So the sweep only ever fired on paths nobody documents, which is where it did the most damage and where nobody would be expecting it.

A missing environment variable must not mean "delete the user's work". Deletion is now opt-in and those two variables are redundant rather than load-bearing. STEMDECK_PERSIST_LIBRARY=0 stays as the one env-based way in, for deployments that set it deliberately.

No supported deployment changes behaviour, because none of them were sweeping.

2. The settings file could not be found (#462)

_SETTINGS_PATH derives from DATA_DIR, which falls back to ROOT when STEMDECK_DATA_DIR is unset, and only the desktop shell sets that. A backend started any other way read backend/settings.json, which does not exist, and silently ignored the stems location, port, device, quality and language the user had chosen.

It now finds the data directory from the layout every package shares: ROOT named backend with a data/ sibling. Not a marker file, because only the Windows package writes one. Docker resolves ROOT to /app and a source checkout resolves it to the repo, so neither is affected. An explicit STEMDECK_DATA_DIR still wins.

This is also what made a directly-run backend a different application with the same files, which is what turned a debugging session into data loss.

3. There was nowhere to see or change it (#463)

Settings > General now has a switch, off by default, that reveals a days field when it is on.

Automatically delete finished tracks    [ off ]
    Delete after  [ 30 ] days            ← only while on

The stored choice beats the environment. That is deliberately the opposite of jobs_dir, where the env pin wins because a mounted volume is not the user's to relocate; how long someone's own work is kept is theirs to decide, and StemDeck is single-user with no separate operator to protect. A tuned STEMDECK_JOB_TTL_SECONDS seeds the default days so existing deployments keep their intent.

There is no "0 means never". In a field reading "delete after N days", 0 most naturally reads as delete immediately, and that ambiguity has no place on the one control that destroys work.

The sweep loop also re-reads the setting every pass. It used to decide once, before its first iteration, which would have made this the only setting in the panel that did nothing until relaunch.

Verified locally, before CI

• Python: 787 passed, against 774 on the unmodified tree. Same 14 pre-existing local failures (beatgrid, worker watchdog) on both.
• Browser: 46 Playwright tests pass, 41 existing plus 5 new covering the reveal, the round trip through a reload, the server-owned ceiling and digit filtering.
• Lint: ruff check and ruff format --check clean; node --check on every static/js/*.js; the tests/js unit tests pass.
• i18n: all eight tables at 443 keys with the coverage script reporting clean, and ptPT overriding only the words that genuinely differ (eliminar, predefinição, anulada).

Release notes

No dependency change, so uv.lock and the runtimeId are untouched and this reaches existing desktop installs through the in-app updater.