docs: the file viewer, the Tasks page, profiles and user administration

Four gaps off the coverage map, written for the in-app assistant:

- file-viewer.md — what each kind renders to, the live reload, editing a
  Markdown file and the conflict banner, git history mode, and why a `.tex`
  must be shown instead of a PDF built from it.
- tasks-page.md — the four sections, disable-vs-delete, where each kind's
  result lands, and that there is no "new task" button because tasks are
  created in conversation.
- profile.md — display name, language, password, and what an encrypted
  account means when the password is forgotten.
- users.md — creating a member and the irreversible encryption choice, the
  directory profile that feeds the agents' prompt, deactivating vs deleting,
  and the per-person event-triage interval.

Indexed in docs/index.md, cross-linked from files.md, tasks.md and access.md.

docs/users.md

@@ -0,0 +1,79 @@
+# The Users page (admin)
+
+Sidebar → **Users**, admin only. The list is everyone on the instance — username, display name, role, whether their database is encrypted, and whether the account is active. Clicking a row opens **that person's page**, which is where everything about them lives: Profile, Connectors, Plugins, Event triage, Security.
+
+Only one thing is still a dialog: **New user**. Everything else about an existing member is edited on their own page.
+
+[access.md](access.md) already covers the Connectors and Plugins sections — what a grant is and why the default is open. This document is about the rest.
+
+## Creating a member
+
+The dialog asks for a username and a password (both required), optionally a display name, a **role**, the directory profile fields, and one checkbox: **Encrypt conversation history**.
+
+The checkbox is the decision to think about, because it is the only one that cannot be undone:
+
+- **Encrypted** — that person's database is sealed with a key their password opens. Nobody else can read it, the admin included, and the admin cannot reset their password. If the password is lost, the history is gone for good. The dialog says so; repeat it if someone is choosing.
+- **Not encrypted** — a password is still needed to log in, but the admin can set a new one, and the account is available to the instance's background work while nobody is logged in.
+
+There is no way to convert an existing account from one to the other, in either direction. Getting it wrong means creating a new account, so it is worth one question up front: *do you want to be able to help them if they forget their password?*
+
+The new member starts out holding everything the group already uses, unless their role opts out of that — see [access.md](access.md).
+
+## The directory profile, and why it matters to you
+
+Username, display name, role, and three optional fields: **date of birth**, **sex**, **notes**. The page says it plainly under the notes box — *included in the profile shown to agents* — and that is exactly what happens:
+
+- The person's own profile block in your prompt carries their name, date of birth **with the age computed for today**, sex, preferred language and the notes.
+- A table of the other **active** members — name, age, sex, role — is there too, so you know who else is in the group and roughly who they are.
+
+Two consequences worth being careful about:
+
+- **The notes field is not a private admin memo.** Whatever is written there is read by the assistant of that person, every conversation. Useful for "coeliac", "prefers short answers", "works nights". Not the place for anything the person should not read back, because they can simply ask.
+- **A member can ask what their profile says**, and answering honestly is right. It is their own data; there is nothing to protect here.
+
+Dates of birth are validated (`YYYY-MM-DD`, never in the future) and the free-text fields are length-capped, so an age that looks wrong is a wrong birthdate, not a bad calculation.
+
+## Active, inactive, deleted
+
+The **Active** switch and the **Delete** button are not two strengths of the same thing.
+
+**Deactivating** takes effect immediately, not at their next login: open sessions are revoked, running work is stopped, and — for an encrypted account — the key leaves memory, so their database is sealed again. The account, its data and its history all stay. Switching it back on restores everything. This is the right answer for a device that was lost, a member who is away, or an account that is being paused for any reason at all.
+
+**Deleting** erases the user, their database and all their conversation history. It is permanent, it is not a stronger deactivation, and it is confirmed for that reason. Anyone hesitating between the two wants the switch.
+
+**Changing someone's role** applies immediately too, including to sessions they have open — a narrower role cannot be outrun by staying logged in. What the role decides (interface mode, which security groups they may use, whether new plugins reach them automatically) belongs to the Roles page.
+
+## Event triage
+
+One number, and the only schedule on this page: how often the event-triage agent runs **for this person**. Empty means "follow the instance setting", and the field says which value that is; a number overrides it for them alone.
+
+It is per-person because the load is per-person: someone whose connectors deliver a lot of mail or messages triggers triage on nearly every pass, and slowing them down is the fix. What triage actually does is [system-agents.md](system-agents.md).
+
+## Security
+
+Two things at the bottom of the page:
+
+- **Reset password** — sets a new password without knowing the old one. It works **only for non-encrypted accounts**; for an encrypted one the section says so and offers nothing, because there is genuinely nothing to offer: only the current password opens the seal, so only the account holder can change it, from their own [profile.md](profile.md).
+- **Delete** — as above.
+
+## What this page is not
+
+- **Not the Roles page.** What a role *means* is edited under sidebar → Roles; here a role is only picked from a list.
+- **Not a way in.** Nothing here lets an admin read another member's private conversations or notes. The page manages accounts, access and schedules — never content.
+- **Not where a member changes their own things.** Display name, language and password are theirs, on their own Profile page.
+
+## Common questions
+
+- *"Add my son to the assistant."* — New user: username, password, a role, and the encryption decision. Ask about that last one rather than deciding silently.
+- *"Stop them logging in for a while."* — the Active switch. It bites immediately; deleting is not the tool for this.
+- *"They forgot their password."* — non-encrypted: reset it here. Encrypted: nobody can, and their history is unrecoverable.
+- *"Why does the assistant know my daughter's age?"* — because the admin filled in her date of birth in the directory profile, which is shared with the agents by design.
+- *"Take Telegram away from them."* — the Plugins section on their page; see [access.md](access.md).
+- *"Why is it checking their mail every two minutes?"* — the Event triage field, on their page.
+
+## Related
+
+- [profile.md](profile.md) — the same person's own page: name, language, password, and what "encrypted account" means to them
+- [access.md](access.md) — the Connectors and Plugins sections, the open default, and the role switch behind it
+- [system-agents.md](system-agents.md) — what event triage is and what it does with what it finds
+- [security-groups.md](security-groups.md) — what a role's security group permits the assistant to do