Add security hardening, Ghidra, recreate skill, checkpoints, shells, web search and themes

- Sandbox (bubblewrap) for non-admin shell/git, MCP per-user rights, hard budgets and quotas,
  login rate limiting, audit log and backups
- Ghidra headless decompilation (ARM64 natives built from source), binary_info tool,
  clean room / deep workflow per session
- Recreate skill and commands for analysing and re-building old software
- File checkpoints with rewind/restore, background shells (bash_output, kill_shell)
- web_search tool (DuckDuckGo, SearXNG, Brave, Tavily)
- In-app dialogs and toasts instead of browser dialogs
- 15 base themes (trilium-themes palettes plus Nord, VS Code, GitHub, Catppuccin, One,
  Dracula, Rose Pine, Everforest, Kanagawa) with light/dark/auto switcher and license notes

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

server/resources/skills/recreate/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: recreate
+description: Re-create existing software (old DOS/Windows/Linux programs and games) as a new, modern implementation – project layout, unpacking, analysis, documentation, specification and a recreation proposal. Use for /recreate-init and /recreate-start.
+---
+
+# Re-creating software
+
+Goal: understand an existing program well enough to build a **new, independent implementation**
+that behaves like the original – on modern systems. We re-create, we do not copy: decompiled
+code is a source of understanding, never of code. Everything we build comes from the
+specification written in our own words.
+
+## Project layout
+
+```
+original/            the user's files: program, libraries, archives, installers (never modified, not committed)
+original/extracted/  unpacked archives and installers (one folder per source file)
+analysis/            tool output: binary_info, decompile results, notes (not committed)
+docs/                documentation of the original (from the templates)
+spec/                specification of the re-creation – the only input for building
+proposal/            the recreation proposal
+src/  tests/         the new implementation and comparison tests (later)
+```
+
+`.gitignore` must exclude `original/` and `analysis/` (third-party binaries and decompiled code
+stay out of the repository).
+
+## Phase 1 – Inventory and unpacking
+
+1. List everything in `original/` recursively with sizes (`find original -type f -printf '%s %p\n'`)
+   and identify each file with `file`.
+2. Unpack every archive and installer **without running it**, each into
+   `original/extracted/<file name>/`, then repeat on the results (archives inside archives,
+   disk images, installers inside archives) until nothing is left to unpack:
+
+   | Found | Command |
+   |---|---|
+   | zip, 7z, tar(.gz/.bz2/.xz), iso, img, NSIS installer, MSI, CAB, many self-extracting .exe | `7z x -y -o<dir> <file>` |
+   | rar, lzh/lha, arj, sit, zoo and other old formats | `unar -o <dir> -f <file>` (or `arj x`, `lha x`) |
+   | Inno Setup installer (`file` or `innoextract -i` says so) | `innoextract -e -d <dir> <file>` |
+   | InstallShield (`data1.cab` + `data1.hdr`) | `unshield -d <dir> x data1.cab` |
+   | Microsoft CAB | `cabextract -d <dir> <file>` |
+   | MSI (if 7z gives no useful names) | `msiextract -C <dir> <file>` |
+   | DOS executables packed with PKLITE/LZEXE/EXEPACK (see `strings`, `binary_info`) | note it – decompile the unpacked image if an unpacker is available, otherwise analyse behaviour and data files |
+
+   If a format cannot be unpacked, record it and continue – never execute installers.
+3. Write `docs/01-inventory.md` (template): every file with origin (which archive), type,
+   size, role guess (main program, overlay, library/driver, data, graphics, sound, music,
+   configuration, save game, documentation).
+
+## Phase 2 – Analysis
+
+1. `binary_info` for every executable and library: format (MZ/NE/PE/LE/ELF), CPU,
+   compiler/linker hints, imports, strings.
+2. `decompile` the main executable(s); for big programs start with `max_functions` and widen.
+3. Explore the output with grep/read: entry point and main loop, initialisation, input,
+   graphics (video modes, palettes, sprites), sound/music drivers, file I/O (which files are
+   opened, how they are parsed), game/application logic, timing, configuration, save games.
+4. Data files: identify formats (headers, magic numbers, `xxd | head`), match them with the
+   loading code, decode them where possible (write small scripts in `analysis/tools/`).
+5. Identify engines, libraries and middleware (strings, imports, copyright notices).
+6. Keep working notes in `analysis/notes.md`. Ask the user (ask_user) when the purpose of
+   something is unclear and they may know it.
+
+## Phase 3 – Documentation and specification
+
+Fill the templates in `docs/` (02–06) from the analysis – in your own words, with function
+addresses only as references. Then write `spec/spec.md`: the behaviour to re-create, screens
+and controls, rules/logic, data and file formats (byte layouts are facts and may be
+specified exactly for compatibility), timing, edge cases, and what counts as "done".
+The spec must be complete enough that someone who never saw the decompiled code could
+build the program from it.
+
+## Phase 4 – Proposal
+
+Write `proposal/recreation-plan.md` (template): 2–3 technology options (e.g. Rust + SDL2,
+C++ + SDL, Godot, web/TypeScript) with fit, pros/cons and effort; the recommended option;
+architecture sketch; milestones (first playable/usable version first); how original assets
+are handled (loaded from the user's original files at runtime vs. new assets); comparison
+tests against the original; risks and open questions.
+
+Then **stop**: summarise the findings and the recommendation for the user and ask with
+ask_user how to proceed. Do not start building before the user agrees.
+
+## Rules
+
+- Never paste or mechanically translate decompiled code into `src/`. Names, structure and
+  code are new. Facts needed for compatibility (file formats, constants, rules) are fine.
+- Original assets (graphics, sounds, levels) stay the user's files: the re-creation may load
+  them from `original/` at runtime but does not copy them into the repository.
+- Use todo_write for the phases; delegate broad searches through decompiled output to
+  explore subagents to keep your own context small.