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/architecture.md

@@ -994,7 +994,8 @@ send it (an older one, or a current one over plain HTTP at a name other than
 `localhost`), `Origin` must name the panel's host - which a form of the panel
 carries under its `Referrer-Policy: same-origin`, the page's own origin (under
 `no-referrer` it would be `null` and refused); a request with neither header
-is let through (an accepted risk). A refusal logs the `Sec-Fetch-Site`,
+is refused too (origin-strict, `2.10.4`; it was let through before, as an
+accepted risk). A refusal logs the `Sec-Fetch-Site`,
 `Origin` and `Host` it compared.
 There are no CSRF tokens — see [security.md](security.md).