[lacutah]

Resolves #901; this is the implementation of what I proposed there, see
#901 (comment) (demo video there). Draft
because the design question raised there is still open — happy to adjust before this lands.

Double-click (and Enter) on a file does nothing today. Rather than deciding "edit" or "download" for everybody in
code, the first gesture asks the user once, remembers the answer, and applies it to that file: Download /
Prefer editor / Ask.

The intent was to stay inside the conventions this repo already has instead of inventing new ones: the preference
is plain localStorage like the show-hidden and sort settings, the dialogs use the existing dialogs.run() idiom,
every string goes through gettext, and a test/check-application case covers the behavior. The UI is unobtrusive
by design: no settings page to discover and nothing happens on first load — the chooser appears only when a gesture
would otherwise do nothing, and once it is answered the gesture just works.

• Unset means status quo — an upgrade changes nobody's workflow — and the choice stays editable from the ⋮ menu.
• "Prefer editor" reuses the existing eligibility check, extracted from menu.tsx into editor_supports() so the
  menu, the gesture and the ask dialog read one gate; files it rejects download. dialogs: Check file content before opening files in the editor #1525 goes on to weigh the bytes
  before the editor opens anything.
• The editor gains a Download button, on the existing download lane and behind the usual "Save changes?" prompt
  when there are unsaved edits.
• Scope caveats: localStorage is per browser profile like the other view preferences (invalid values degrade to
  "not set"), symlinks stay no-ops as in the context menu, and Enter/ArrowDown ignore key auto-repeat now that the
  gesture does something.
• Pixel references: the extra editor footer button changes editor-modal-changed* and editor-modal-read-only*
  (all layouts), so testEditor will fail the first CI run. I'll grab the new images with
  test/common/pixel-tests fetch from that run's log dir and add the test/reference bump as its own commit,
  which looks like the intended flow for a pixel-changing PR.

The new TestFiles.testDefaultFileAction passes on fedora-44 / chromium in the nested-VM harness — worth stating,
as a draft PR gets no CI until a maintainer runs it.

I wrote this with an AI coding assistant (opencode + Qwen); I reviewed, tested, and carry every line myself.

---

Files: Configurable default file action

Files can now answer a double-click (or Enter) the way their user wants: download, open in the editor when the file
looks editable, or ask each time. The answer is given once in a first-run dialog and lives in the ⋮ menu afterwards.
The file editor also gained a Download button that works even with unsaved changes.