Add plain-language concept docs; fix docs viewer rendering; link API tokens

- New docs/concepts-{hosts,dns,access,api-tokens}.md -- plain-language
  guides aimed at less technical readers, each linking onward to the
  existing system-design-level doc for anyone who wants that detail.
  Card help links (Proxy List, Add/Edit host, DNS Provider cards,
  Users/Permissions/Groups cards) now point here instead of straight at
  Installation/Architecture.
- The "New API Token" card had no help link at all -- added, pointing to
  the new API Tokens doc.
- Fixed the in-app docs viewer rendering every docs/*.md page with a
  garbled heading + stray <hr> at the top: Jekyll front matter (meant
  only for the GitHub Pages build) was never stripped before being
  handed to the markdown renderer.
- Fixed cross-doc links never resolving in-app, since this viewer serves
  docs at /docs/<slug> with no .html suffix: rewritten to the correct
  in-app URL, first by registered slug, falling back to the doc's real
  filename (the correct, working link form on the Jekyll/GitHub Pages
  build) -- same idea as the existing image-path fix, and lets one link
  written in a doc work on both targets.

Bumps to v1.1.13.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KDEx8ghuZR61pqPXc6da9C

docs/architecture.md

@@ -8,6 +8,11 @@ description: How the proxy's OIDC client, LDAP client, and OpenResty routing fit
 
 [← Back to Home](index.html)
 
+> Looking for a plainer explanation of hosts, HTTPS, or the local
+> permission model instead of internals? See
+> [Hosts & HTTPS](concepts-hosts.html) and
+> [Users, Groups & Permissions](concepts-access.html).
+
 ## System Overview
 
 The proxy system consists of three main components working together to provide high-performance reverse proxying with automated SSL management.

docs/concepts-access.md

@@ -0,0 +1,75 @@
+---
+layout: default
+title: Users, Groups & Permissions
+description: A plain-language guide to local admin accounts, groups, and the domain-scoped permission model in theta42/proxy.
+---
+
+# Users, Groups & Permissions
+
+This page explains, in plain language, who can manage what in this app. For
+the deeper system-design detail, see [Architecture](architecture.html).
+
+## Two different ways to log in
+
+Most people who use apps you've proxied through this app never see this
+app's own login at all — they use whatever authentication you set up on
+the *individual host* (basic auth, or single sign-on through your SSO
+Manager). This page is about a different, smaller group: the people who
+manage the proxy itself — adding hosts, registering DNS providers, and so
+on.
+
+There are two ways someone gets into the proxy's own management UI:
+
+- **A local account**, created on the **Users** page — a username and
+  password specific to this app.
+- **Single sign-on**, if you've connected this proxy to an SSO Manager (or
+  another OIDC provider) — the same login your other connected apps use.
+
+Either way, once logged in, what they're actually *allowed to do* here is
+controlled by permissions, described below.
+
+## Groups
+
+A **group** here is just a named list of local usernames, used to grant
+the same permission to several people at once instead of one at a time.
+If you're using SSO instead of local accounts, group membership normally
+comes from your identity provider instead — local groups exist mainly for
+the local-account case.
+
+## Permissions: scope + role
+
+Each **permission** entry grants one subject (a user or a group) one
+**role**, at one **scope** — the two are independent choices:
+
+**Scope** — *where* the role applies:
+
+- **Domain** — only hosts under one specific domain (e.g. someone can
+  manage everything under `example.com`, but can't see or touch a
+  completely different domain you also proxy).
+- **Global** — everywhere, across every domain this proxy manages.
+
+**Role** — *what* they can do within that scope:
+
+- **Viewer** — read-only. Can see hosts and their settings, but not
+  change anything.
+- **Manager** — full control over hosts (create, edit, delete) within
+  that scope.
+- **Admin** — same host control as Manager, **plus**, but *only when
+  granted at Global scope*, the ability to manage other people's
+  permissions, DNS providers, and local user accounts. An Admin role
+  granted at Domain scope instead of Global behaves exactly like Manager
+  for that one domain — it does not unlock those extra admin-only pages.
+
+In practice: give someone **Manager** on just the domain(s) they're
+responsible for to delegate day-to-day host management without handing
+them the keys to everything. Reserve **Global Admin** for people who
+should be able to change anything, anywhere, including who else has
+access.
+
+## Want more detail?
+
+This page doesn't cover the exact permission-checking implementation or
+how SSO group membership maps into this system internally — for that, see
+[Architecture](architecture.html).
+
+[← Back to Home](index.html)

docs/concepts-api-tokens.md

@@ -0,0 +1,60 @@
+---
+layout: default
+title: API Tokens
+description: A plain-language guide to personal access tokens in theta42/proxy.
+---
+
+# API Tokens
+
+This page explains what an API token is and when you'd want one. For the
+full list of API endpoints a token can call, see the
+[API reference](api.html).
+
+## What's an API token, in plain terms?
+
+Normally, you interact with this app by logging in through a web browser.
+An **API token** (also called a personal access token, or PAT) is an
+alternative way in — a long, random string that a script, a scheduled job,
+or another program can use instead of a username and password, to act on
+your behalf without a human typing a login in each time.
+
+If you've ever set up a script to talk to GitHub, GitLab, or a similar
+service using a "token" instead of your real password, this is the same
+idea.
+
+## When would you actually need one?
+
+Most people never need to create one of these — you'll only want a token
+if you're automating something, for example:
+
+- A script that registers or updates hosts automatically (say, spinning up
+  a new service and wanting the proxy entry created for it without a
+  manual step).
+- A monitoring or backup job that checks this app's health via its API.
+- A configuration-management tool that keeps your host list in sync with
+  something else.
+
+If you're not doing any of that, you don't need an API token — just log in
+normally through the web UI.
+
+## How it works
+
+Create a token from your Profile page, give it a name so you remember what
+it's for later, and optionally an expiry. You'll be shown the token's
+value **exactly once** — copy it somewhere safe immediately, because it
+can't be viewed again afterward (only revoked or rotated). Whatever script
+or tool you're using it with sends it along with each request, the same
+way a browser sends your login session.
+
+A token acts **as you**, with **your** [permissions](concepts-access.html)
+— if you're only a Manager on one domain, a token you create can't touch
+any other domain either. If you ever suspect a token has leaked (ended up
+somewhere it shouldn't have, like a public script or log file), revoke it
+immediately from your Profile page; it stops working right away.
+
+## Want more detail?
+
+This page doesn't attempt to list every API endpoint or show request/
+response examples — for that, see the full [API reference](api.html).
+
+[← Back to Home](index.html)

docs/concepts-dns.md

@@ -0,0 +1,49 @@
+---
+layout: default
+title: DNS Providers
+description: A plain-language guide to why theta42/proxy needs a DNS provider, and only for wildcard certificates.
+---
+
+# DNS Providers
+
+This page explains, in plain language, what a "DNS provider" is for in this
+app and when you actually need one. For setup steps, see
+[Installation](installation.html).
+
+## Do you need this at all?
+
+**Only if you want a [wildcard host](concepts-hosts.html)** (something like
+`*.example.com` covering every subdomain with one certificate). A normal,
+single-name host doesn't need a DNS provider configured at all — skip this
+page entirely if that's all you're setting up.
+
+## Why a wildcard cert needs this extra step
+
+To prove you actually own `example.com` before issuing a certificate that
+covers *every* possible subdomain of it, Let's Encrypt needs to see a
+specific, temporary DNS record appear on that domain — something only the
+real owner of the domain could add. A normal single-host certificate
+doesn't need this because it can prove ownership a simpler way (by
+responding to a web request instead).
+
+So: to get a wildcard certificate, this app needs to be able to add (and
+later remove) that one temporary DNS record on your domain automatically,
+which means it needs your domain registrar or DNS host's API credentials —
+that's what registering a **DNS provider** here does.
+
+## What you're actually giving it access to
+
+A DNS provider entry only needs enough access to add/remove TXT records —
+it's not given your registrar account's full login, and it can't do
+anything to your domain besides that one narrow task (and, for some
+providers, keeping a dynamic A record updated if you use that feature
+separately). Check your specific provider's page in the
+[Installation guide](installation.html) for exactly what kind of
+credential to generate and how narrowly you can scope it.
+
+## Want more detail?
+
+For exact setup steps per provider (Cloudflare, DigitalOcean, Porkbun,
+DuckDNS, etc.), see [Installation](installation.html).
+
+[← Back to Home](index.html)

docs/concepts-hosts.md

@@ -0,0 +1,77 @@
+---
+layout: default
+title: Hosts & HTTPS
+description: A plain-language guide to hosts, HTTPS certificates, and wildcards in theta42/proxy.
+---
+
+# Hosts & HTTPS
+
+This page explains, in plain language, what a "host" is and how this app
+gets you working HTTPS without you having to think about certificates. For
+the deeper system-design detail, see [Architecture](architecture.html); for
+step-by-step setup, see [Installation](installation.html).
+
+## What's a "host"?
+
+A **host** is one entry telling the proxy: "when someone requests *this*
+public address, send them to *that* server." For example: requests for
+`photos.example.com` get sent to the little box in your closet running your
+photo app on port 8080. Each app or service you want to reach from outside
+your network — a home automation dashboard, a media server, this proxy's
+own management UI — gets its own host entry.
+
+Two settings on a host are easy to mix up:
+
+- **Incoming host name** — the public address people type in their
+  browser (`photos.example.com`).
+- **Target IP/port** — where the proxy actually sends the request behind
+  the scenes (`10.0.0.5:8080`, or a hostname like `photo-server`).
+
+Everything else on the host form (traffic limits, access rules,
+authentication) is optional — a bare host with just those two fields
+already works.
+
+## HTTPS certificates: mostly automatic
+
+Every public website needs an HTTPS certificate so browsers show the lock
+icon instead of a scary warning. This app gets one for you automatically
+from [Let's Encrypt](https://letsencrypt.org) the first time a host is
+actually requested — you don't manually request, install, or renew
+anything for a normal host. This happens behind the scenes using a method
+called **HTTP-01**, and it's the default for every new host.
+
+## Wildcards: one certificate for a whole family of hosts
+
+Sometimes you want *every* subdomain under one name to work — `app1.`,
+`app2.`, `anything.example.com` — without registering each one by hand and
+waiting for its own certificate. That's what a **wildcard** host does: a
+single host entry named `*.example.com` gets one certificate that covers
+the whole family at once. Setting one up needs one extra piece of
+information the automatic method above doesn't need — see
+[DNS Providers](concepts-dns.html) for why.
+
+Once a wildcard exists, you have two ways to actually use it:
+
+- **Register nothing else, and turn on "Match any subdomain"** on the
+  wildcard host itself — *any* subdomain that doesn't already have its own
+  entry gets automatically routed to the wildcard's target the first time
+  it's requested. Convenient, but it means literal typos and random scan
+  traffic get routed too, not just the subdomains you meant to use.
+- **Register each subdomain as its own host, as a "Parent Wildcard"
+  child** — more setup, but each subdomain can point at a different
+  target/server while still reusing the one wildcard certificate instead
+  of getting its own. This is the recommended default and is what
+  "Match only subdomains defined here" (the host form's default) does.
+
+You'll see the **"Parent Wildcard"** option light up automatically on the
+host form whenever the name you're entering already has a matching
+wildcard available to reuse — including the wildcard's own bare base
+domain (e.g. `example.com` itself, not just `something.example.com`).
+
+## Want more detail?
+
+This page skips the system-internals (Redis, OpenResty, the lookup service)
+and the exact install steps. For those, see
+[Architecture](architecture.html) and [Installation](installation.html).
+
+[← Back to Home](index.html)

docs/installation.md

@@ -8,6 +8,10 @@ description: Installing the proxy — Docker, bare metal, or as part of the unif
 
 [← Back to Home](index.html)
 
+> Looking for a plainer explanation of hosts, HTTPS, and DNS providers
+> instead of install steps? See [Hosts & HTTPS](concepts-hosts.html) and
+> [DNS Providers](concepts-dns.html).
+
 ## Quick Install (Recommended)
 
 For modern Debian-based systems (Ubuntu 20.04+, Debian 11+):