Fix the end screen layout, make the app responsive, document secrets

End screen
- There was an auto-fit routine that forced this screen into one viewport: it
  shrank the graph to a 120px floor, trimmed the Play Again margin, then
  capped the passage box at 80px with its own scrollbar. On a 650px window
  that left the passage 80px tall and clipped, and the graph 120px, which are
  the two things the screen exists to show. Removed. The page scrolls
  instead, which is the right trade for a screen that is read rather than
  acted on under time pressure.
- The screen is a flex column, so its children also shrank by default once
  the content was taller than the viewport. The passage, graph, stat row and
  standings no longer shrink, and the chart has a floor below which it stops
  carrying information.

Bottom chrome
- The keyboard hint and the footer links were both fixed at bottom centre and
  overlapped at every window size. The hint now sits above the footer.
- Normal-flow content could end up underneath the fixed footer and the corner
  rails. One --bottom-chrome variable reserves that space on every screen.
- On a narrow screen the footer grows to the full width once its links wrap,
  so at 375px it ran through both corner rails and covered Play Again, which
  made the button unclickable. The chrome stacks there instead: rails on the
  bottom line, footer above them, hint above that.

Mode picker
- It ran to the last pixel of the window at every size. It now keeps clear of
  the bottom edge, and opens upward when a short window leaves more room
  above than below.

Responsive
- Checked at nine viewports from 1920x1080 down to 375x667: no horizontal
  overflow and nothing off-screen on the menu, the typing screen or the end
  screen.

Configuration
- dotenvy searches upward from the working directory, so crates/server/.env
  was only found when starting the server from that directory. The repository
  root is tried as well, which is where it is usually started from.
- .env.example and the README explain where secrets belong: the environment,
  a gitignored .env for local work, and EnvironmentFile or a platform secret
  store in production. Also what to do if one is exposed.
- TYPERPUNK_ADMIN_USERNAME and TYPERPUNK_ENV are documented rather than left
  to be discovered in the source.

1 files changed, 29 insertions, 0 deletions

diff --git a/README.md b/README.md
index 7d00e3f..615a2ec 100755
--- a/README.md
+++ b/README.md
@@ -179,6 +179,35 @@ rather than warnings.
 Terminate TLS at the proxy and send HSTS from there. The application sets the
 other security headers itself.
 
+### Secrets
+
+Every setting is read from the environment. Copy `crates/server/.env.example`
+to `crates/server/.env` for local work. That file is gitignored and is the
+only place a password or a client secret belongs.
+
+In production, prefer real environment variables to a file on disk. A systemd
+unit can take them from `EnvironmentFile=`, with the file owned by root and
+mode 600:
+
+```ini
+[Service]
+EnvironmentFile=/etc/typerpunk/env
+ExecStart=/usr/local/bin/typerpunk-server
+User=typerpunk
+```
+
+Container runtimes and hosting platforms have their own secret stores. The
+server reads plain environment variables in every case, so nothing in the
+application changes.
+
+Do not put a secret in `.env.example`, in a commit message, or in an issue.
+If one is exposed, rotate it: change the database password, restart the
+server, and invalidate sessions by clearing the `sessions` table.
+
+The first administrator is created by setting `TYPERPUNK_ADMIN_USERNAME` to an
+account that has already registered. Unset it afterwards. It exists to create
+the first administrator and to recover if the last one is removed.
+
 ## Development
 
 ```bash