Oregami has no login, and adding one drags in CSRF defence and content-type checking

Nothing in the forge is authorised by a cookie or a session. A write carries its credential in the form body itself, and `src/form.rs:19-26` states the consequence as a design property: "Nothing in this forge is authorised by a cookie or a session ... a cross-site submission is a submission with no voice and is refused like any other. That is why the content type is not checked." A real login overturns that. The moment a cookie carries authority, a cross-site form POST is authorised by the browser's own cookie jar, and both of the properties that sentence rests on disappear at once: CSRF immunity, and the licence to skip content-type checking. The second is the one that is easy to miss, because it reads as an optimisation and is actually load-bearing -- it is only safe while the credential must be supplied by the submitter. The decision was taken with that cost stated. A session store, a sign-in page, a cookie, expiry, revocation and logout are wanted; and they come with CSRF tokens on every write form, `SameSite=Strict`, and content-type checking on every write. It is sequenced last, after the JSON routes, the votes and the vhost with its certificate, all three of which are now done. Sequencing it last is not a way of avoiding it. It is a way of not building an ambient-authority surface while the rest of the write path is still moving, since every form added before the login is a form that will need a token afterwards. What remains is the build, and a sweep of every write route to confirm nothing has been added in the meantime that assumes the sessionless posture. Transcribed from the project record on 2026-08-14. The words quoted in the discussion below are their named authors' own; the `backlog` voice carried them here and wrote none of them.