Run the sync server image as a numeric UID/GID; explain unwritable /data

The image now runs as USER 10001:10001 with a matching group, so
Kubernetes can verify runAsNonRoot and fsGroup: 10001 grants it a mounted
volume. When the database can't be opened because its directory isn't
writable, the server says so and how to fix it, instead of SQLite's bare
"unable to open database file". The README covers the pod securityContext.

README.md

@@ -197,6 +197,23 @@ answers `ok` for probes. Keep `MTGC_OIDC_CLIENT_SECRET` in a Secret. Run the
 account commands with `kubectl exec -it deploy/<name> -- mtgc-server user add
 <name>`.
 
+A freshly provisioned volume is usually owned by root, which the server
+(UID/GID 10001) can't write to — it fails at startup with "`/data` isn't
+writable". Have Kubernetes hand the volume to its group in the pod spec:
+
+```yaml
+spec:
+  securityContext:
+    runAsNonRoot: true
+    runAsUser: 10001
+    runAsGroup: 10001
+    fsGroup: 10001
+```
+
+A few volume types ignore `fsGroup` (`hostPath`, and some NFS and local-path
+provisioners). For those, `chown 10001:10001` the backing directory once, or
+add an init container that does it.
+
 To build the image yourself and push it to your own registry:
 
 ```bash