origin-strict: a change with neither Sec-Fetch-Site nor Origin is refused

Agreed with the owner on 2026-10-13 (in place of csrf-tokens), taken up on
2026-10-16 ("Да"). originAllowed (internal/web/security.go) returns false
in the "neither header" branch: such a POST is answered 403 and logged
like a cross-origin one. It was let through until now as an accepted
risk, which left a browser that sends neither open to a request forged by
any site. A browser that follows Fetch § 3.2 never sends a POST without
Origin; one too old to (Firefox before 70) can no longer save anything.

What posts to the panel without a browser: the e2e suite's client, which
now sends Origin on every form (panelClient.postForm); cmd/panel's tests
already did. Nothing else posts to it (the CLI runs in the container).

Tests: security_test's case of no headers is refused; e2e posts with
neither header and gets 403 (testFormPostWithTheBrowsersOrigin). go vet +
go test (26 packages) and make e2e on the test server for this tree.

Docs: security.md - the accepted risk struck, the ADR's decision and
trade-off say refused, the origin-check bullet; architecture § Web,
guide § the proxy; CHANGELOG [Unreleased] § Security; roadmap row done.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/guide.md

@@ -295,6 +295,9 @@ browser that does not send `Sec-Fetch-Site` (Safari before 16.4, or any
 browser on a panel served over plain HTTP at a name): there the panel compares
 `Origin` with `Host` and refuses every change as cross-origin - the log says
 so explicitly, printing the `Sec-Fetch-Site`, `Origin` and `Host` it compared.
+A request that carries neither header - a browser too old to send `Origin`,
+or a script posting to the panel without one - is refused the same way
+since 2.10.4.
 
 In every case the proxy terminates HTTPS for the panel; the resulting
 certificate must end up under `./certs` as `fullchain.pem` and `privkey.pem` —