docs: split reference material into docs/, keeping the README a shop window (v0.23.4-beta)

Documentation only — no functional change.

The README was carrying two jobs for two different readers. Its Reference section was
the single largest block at 154 lines, and nobody deciding whether to try the project
reads an InfluxDB environment variable table — while the people who need it were
scrolling past the pitch to reach it.

Split along that seam: anything you would read before installing stays in the README,
anything you would read after installing moves to docs/.

  README.md              430 lines   sell, prove, install, feature overview
  docs/change-guard.md   193         safety system, settings, guard states
  docs/architecture.md   116         data stores, polling model, module layout
  docs/capsman.md         84         role model, radio matching, current limits
  docs/alerting.md        81         rules, channels, webhooks, maintenance windows
  docs/api.md             77         scoped tokens, preflight, scripting
  docs/configuration.md   76         environment, secrets, rotation, TLS
  docs/sso-oidc.md        71         identity provider setup and behaviour
  docs/README.md          20         index

In-repo rather than a documentation site, deliberately. A change to Change Guard's
semantics can edit its documentation in the same commit as the code — which, given how
often that behaviour has been refined recently, is the property that actually matters.
A static site generator can point at docs/ later without moving a file.

The Change Guard pitch stays on the front page: the problem framing, the verified
recovery timeline and the quoted prediction warning are what make someone care, and a
reference page is the wrong home for them.

Three sections are new rather than relocated, written because the split exposed the gaps:

  - architecture.md did not exist. It now records why there are three data stores, the
    polling cadences, and which modules are pure functions over a snapshot and why.
  - Scoped API tokens shipped without usage documentation. api.md shows preflighting a
    change from a script and reading the guard block afterwards.
  - change-guard.md records why ip-on-bridge-port is informational rather than critical
    on RouterOS 7 — reasoning that previously existed only in a commit message.

Every internal anchor and cross-file link verified to resolve, including anchors into
other documents. No content dropped, checked by keyword comparison against the previous
single file.

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

docs/api.md

@@ -0,0 +1,77 @@
+# API and automation
+
+[← Documentation index](README.md)
+
+The web UI is a client of the same REST API you can drive yourself. Anything the interface
+does is available to a script.
+
+## Scoped API tokens
+
+Issue tokens under **Settings → Automation**.
+
+- Prefix `mtm_…`, with **read** or **write** scope and an optional expiry
+- Shown **once** on creation — only a SHA-256 hash is stored
+- Mapped onto the role model: no token can perform admin actions or manage other tokens,
+  regardless of scope
+
+```bash
+curl -sk https://manager.example.com/api/devices \
+  -H "Authorization: Bearer mtm_your_token_here"
+```
+
+A token with `read` scope is rejected on any mutating request, so a monitoring integration
+cannot change your network even if the token leaks.
+
+## Session authentication
+
+The UI authenticates with a JWT obtained from `/api/auth/login`, optionally followed by
+`/api/auth/totp/verify` when two-factor is enabled. Tokens are bearer credentials and are
+sent in the same `Authorization` header.
+
+For scripting, prefer an API token — it is scoped, revocable, and unaffected by password
+or 2FA changes.
+
+## Endpoints worth knowing
+
+| Endpoint | Purpose |
+|---|---|
+| `GET /api/devices` | Fleet inventory with status, model, versions and serials |
+| `POST /api/devices/:id/sync` | Force an immediate full collection for one device |
+| `GET /api/devices/:id/management-path` | How the manager reaches a device, with the reason for each hop |
+| `POST /api/devices/:id/preflight` | Analyse a change **without applying it** |
+| `POST /api/devices/:id/change-guard/probe` | Report which safety mechanisms the device supports |
+| `GET /api/devices/:id/config-health` | Latest standing-audit findings |
+| `GET /api/topology` | Graph of devices, links, external nodes, and distrusted identifiers |
+| `GET /api/operations/insights` | The dashboard's "things to handle" feed |
+
+`preflight` is the useful one for automation: it returns the same verdict the UI shows,
+so a pipeline can refuse its own change before touching the device. See
+[Change Guard](change-guard.md#lockout-prediction).
+
+## Applying a guarded change from a script
+
+Guarded endpoints return **409** with `lockout: true` and a verdict when a change is
+predicted to sever management. To proceed anyway, resend with `confirm_lockout: true` —
+the change then runs under Change Guard, so a mistake still recovers itself.
+
+```bash
+# Refused, with an explanation
+curl -sk -X PUT https://manager.example.com/api/devices/8/ports/ether1/vlan \
+  -H "Authorization: Bearer mtm_…" -H 'Content-Type: application/json' \
+  -d '{"pvid":99,"tagged_vlans":[],"untagged_vlans":[99]}'
+
+# Accepted, relying on auto-revert
+curl -sk -X PUT https://manager.example.com/api/devices/8/ports/ether1/vlan \
+  -H "Authorization: Bearer mtm_…" -H 'Content-Type: application/json' \
+  -d '{"pvid":99,"tagged_vlans":[],"untagged_vlans":[99],"confirm_lockout":true}'
+```
+
+A successful guarded change returns a `guard` block describing what happened —
+`confirmed`, `auto_reverting`, or an `unprotected_reason` when the safety net could not be
+armed. Check it rather than relying on the HTTP status alone.
+
+## Webhooks
+
+For push rather than poll, see [Alerting → outbound webhooks](alerting.md#outbound-webhooks).
+Deliveries are HMAC-SHA256 signed and respect alert rules, cooldowns and maintenance
+windows.