test+docs: startup-refusal exit code, real-body 413, pre-1.1.0 migration note

- main() exits 2 on permissive config (not just the predicate)
- 413 proven with an actual over-limit wire body, not header-only
- README: machine-user accounts need a seeded state.json mapping; only
  granthi-sync-e2e required it in beta

Co-Authored-By: Claude Fable 5 <[email protected]>

README.md

@@ -74,6 +74,16 @@ A Gitea token is **never minted before the binding rule passes**, and a
 corrupt/unreadable `state.json` fails closed (500) instead of falling back
 to an empty map.
 
+**Migration (pre-1.1.0 accounts):** identities whose userinfo carries no
+verified `email` (e.g. Zitadel *machine* users) cannot self-adopt an
+existing forge login under rule (c) — for them the first link after the
+upgrade would 409 forever. Any forge account the v1 service created before
+this change must be seeded into `state.json` once, as
+`{"<sub>": {"login": "<login>", "created_by_service": true, ...}}`, written
+0600 atomically. As of the beta rollout the only such account is the E2E
+machine user `granthi-sync-e2e` (seeded); the forge's human admin `nirpa`
+is never provisioned through `/v1/link`, so nothing else needed seeding.
+
 Empirically verified mechanics on Gitea **1.27.1** (beta forge):
 
 * Token minting: `POST /api/v1/users/{login}/tokens` returns **401 for