docs: a guide, a wiki and screenshots

The README grew a section per feature and is a good reference, but nothing
said where to begin. docs/wiki now has a getting-started page, a guide that
walks through one day with the workspace and explains each part where it comes
up, and a page per part of the app, each with screenshots of what it
describes.

Three pages are read out of the code rather than written, so they cannot drift
from it: the keys and commands from Help.svelte and commands.ts, the same lists
`:help` draws; the settings from .env.example, which gains a heading for the
vault, trash and history settings so they no longer sit under mail; and the
API from the README's table. `make wiki` writes them, and `--check` fails when
one is stale or a link between pages leads nowhere. `--publish` lays the pages
out for a GitHub wiki: links without `.md`, images beside them, `[[` escaped so
the wiki does not take a command's help text for a link to a page.

The screenshots are taken by `make screenshots`: the debug binary on a
temporary data directory, with a password made up for the run, filled with an
example workspace over the API, and a headless Chromium driven over the
DevTools protocol through the views the docs show. Nothing outside the
temporary directory is touched but docs/images, and the pictures are cut to
256 colours, a third of their size, which a dark UI does not show.

The README opens with the banner, a CI badge, the guide, the features grouped
by what they are for, and six of the screenshots.

docs/wiki/Development.md

@@ -0,0 +1,107 @@
+# Development
+
+## Running it from source
+
+```sh
+make dev-api   # cargo run, serving the API on :4242
+make dev-web   # vite on :4243, proxying /api to :4242
+```
+
+Open <http://127.0.0.1:4243>. The Rust build embeds `web/dist`, so build the
+frontend once (`cd web && bun install && bun run build`) before the first
+`cargo build`; a debug build reads `web/dist` from disk after that.
+
+Point `WORKSPACE_DATA_DIR` at a throwaway directory while trying things, so the
+real data stays out of it.
+
+## The code
+
+| where | what |
+| --- | --- |
+| `src/main.rs` | start-up, the router, security headers, background loops |
+| `src/routes/` | one module per area of the API: `nodes`, `boards`, `trash`, `revisions`, `links`, `capture`, `diary`, `media`, `file_text`, `seal`, `share`, `import`, `export` … |
+| `src/sftp/` | the SFTP mount |
+| `src/backup/` | the Proton Drive mirror |
+| `src/mail/`, `src/notify/` | the outbox, and what is worth a mail |
+| `src/vault.rs` | the vault's keys and file format |
+| `src/sweep.rs` | the daily clean-up: trash, old versions, unreferenced uploads |
+| `migrations/` | the SQLite schema, one numbered file per change |
+| `web/src/App.svelte` | the keys |
+| `web/src/lib/store.svelte.ts` | the client's state, and every call to the API |
+| `web/src/lib/commands.ts` | the `:` commands |
+| `web/src/lib/Help.svelte` | the `?` screen |
+
+The database is one SQLite file with FTS5 for search. Every migration is
+applied at start, after a copy of the database is kept as
+`diary.db.pre-<version>`. Many rules are enforced by triggers as well as in the
+code, so no path can break them: a sealed file has no indexed text, a file in a
+sealed folder is sealed, the diary cannot be deleted.
+
+## Checks
+
+```sh
+make check
+```
+
+runs what CI runs:
+
+- `cargo fmt --check`
+- `cargo clippy --all-targets -- -D warnings`
+- `cargo test`
+- `bun run check` in `web/` (svelte-check)
+
+The Rust tests run against an in-memory database; most modules have a test
+block at the bottom.
+
+## CI
+
+`.github/workflows/ci.yml` runs on every push and pull request:
+
+- **rust**: builds the frontend (the binary embeds it), then format, clippy
+  and the tests;
+- **web**: svelte-check;
+- **docs**: checks that the generated wiki pages are up to date and that every
+  link between the pages resolves.
+
+`.github/workflows/wiki.yml` publishes `docs/wiki` to the GitHub wiki on every
+push to `main` that changes it, or changes a file the generated pages are read
+from.
+
+## The wiki
+
+The pages live in `docs/wiki` and the pictures in `docs/images`. Edit them
+there; an edit on GitHub's wiki page is overwritten by the next publish.
+
+Three pages are generated by `scripts/wiki.ts`:
+
+| page | read from |
+| --- | --- |
+| [Keys and commands](Commands.md) | `web/src/lib/Help.svelte` and `web/src/lib/commands.ts` |
+| [Configuration](Configuration.md) | `.env.example` |
+| [API](API.md) | the API section of `README.md` |
+
+After changing one of those, run `make wiki` and commit the result. CI fails
+when they are stale.
+
+Links between pages are written as `Page-Name.md` so that they work when the
+files are read in the repository; the publish step drops the `.md` for the
+wiki.
+
+## Screenshots
+
+```sh
+make screenshots
+```
+
+builds the app, starts it on a temporary data directory with a password made
+up for the run, fills it with an example workspace, and drives a headless
+Chromium through the views the docs show. The pictures are written to
+`docs/images`. It needs `chromium` on the path (or `CHROMIUM=/path/to/chrome`),
+and shrinks the pictures with ImageMagick when it is installed.
+
+## Conventions
+
+- One finished feature per commit, with the README, `:help` and the tests in
+  the same commit.
+- Commit messages are `area: a sentence`, followed by prose about why.
+- Comments explain why, not what.