docs: two pages that state the opposite of what the code does

docs/HARDWARE.md

@@ -68,9 +68,17 @@ Three consequences worth knowing:
   first two fields is the whole problem, so the API refuses to collapse them.
   `GET /api/v1/encoders?redetect=1` re-runs the scan — plug a GPU in, install a
   driver, fix a permission, then re-detect, no restart needed.
-- **`libx264` stays the default even on a machine with a working GPU.** Its
-  behaviour is identical everywhere; hardware wrappers vary by driver version.
-  Hardware is an opt-in you make deliberately.
+- **A working hardware encoder becomes the default for a new rendition**, in
+  the order VideoToolbox, NVENC, QSV, VA-API, AMF, then `libx264`. "Working"
+  means it passed the probe — the build merely listing an encoder is not
+  evidence, and defaulting to a listed-but-dead one is how an operator finds out
+  about `libcuda` after going live. If every probe fails, including x264's, the
+  default is `libx264` anyway: that keeps the product usable and the failure
+  legible, where an empty `-c:v` is neither.
+
+  You can still choose `libx264` per rendition, and there are reasons to — its
+  behaviour is identical everywhere, while hardware wrappers vary by driver
+  version. But it is an override, not the starting point.
 
 ---
 

docs/PLATFORMS.md

@@ -345,8 +345,21 @@ categories by name rather than by numeric id), carries chat both ways, and
 reports viewer counts.
 
 Scopes requested: `user:read`, `channel:read`, `channel:write`, `chat:write`,
-`moderation:chat_message:manage`, `events:subscribe`, `streamkey:read`. `moderation:ban` is
-deliberately not requested: nothing in polyemesis bans or times out a viewer.
+`moderation:chat_message:manage`, `moderation:ban`, `events:subscribe`,
+`streamkey:read`.
+
+`moderation:ban` covers banning and timing out a viewer, and lifting either. It
+was deliberately omitted at first, on the grounds that nothing here banned
+anyone and that asking a restreamer's audience for the power to do so read as
+overreach. That was reversed when moderation shipped: automod's action matrix
+includes timeout and ban, so the scope is requested up front rather than asked
+for silently later. The original argument is kept in `internal/oauth/kick.go`
+rather than deleted, because it is what to re-read if the decision is revisited.
+
+Adding a scope later does **not** upgrade an existing connection — it forces
+every operator to disconnect and reconnect, and discovering that mid-broadcast
+is the worst possible moment. That is why the list is settled in one go rather
+than grown as features land.
 
 Kick delivers chat over a webhook rather than a socket, so the chat pane needs a
 public HTTPS URL Kick can reach. Without one it says so rather than sitting