fix: allow Safari null origins on bridge login

[Amplify-Logic]

Intent

Bridge login: treat Origin: null as absent - the captain's real Safari sends it.

Definitive captured evidence (2026-08-19 15:42:15, transparent header tap in front of the live service): the captain's iPhone Safari (iOS 18.7 UA, Version/26.6) submits the same-origin login form with Origin: null (the literal string - Safari privacy masking) plus Sec-Fetch-Site: same-origin, Sec-Fetch-Mode: navigate, no Referer. Current _origin_ok() in bin/fm-bridge-view.py takes the present-Origin branch, compares "null" against the expected origins, and 403s - so the captain has never once logged in from his phone.

Change, surgical: in _origin_ok(), treat a literal null Origin (case-insensitive) exactly like an ABSENT Origin, falling through to the existing same-origin proofs (Sec-Fetch-Site same-origin/none, else https Referer host match). A present Origin that is neither null nor matching stays rejected. Brief inline comment citing Safari's privacy masking; update the one relevant paragraph in docs/bridge-view.md.

Tests: replicate the captured request shape exactly (Origin: null + Sec-Fetch-Site: same-origin + form content type -> login succeeds with correct passcode); Origin: null with NO same-origin proof -> rejected; existing origin tests unchanged.

Scope is exactly this branch change - nothing else. After the PR is green and merged, firstmate redeploys and live-verifies; that redeploy is out of scope for this change.

What Changed

• Treat case-insensitive Origin: null bridge login requests like an absent Origin, requiring existing Fetch Metadata or HTTPS Referer same-origin proof.
• Document Safari’s privacy-masked null Origin behavior.
• Add regression coverage for accepted same-origin and rejected unproven null Origin requests.

Risk Assessment

✅ Low: Captain, the change is tightly scoped, matches the authoritative intent, preserves the existing CSRF proof requirements, and adds focused regression coverage.

Testing

Inspected the complete three-file change, ran the focused bridge behavior suite successfully, and exercised the live HTTP login endpoint with positive and negative null-Origin requests; the captured transcript demonstrates the intended 303 login/session behavior and required 403 fail-closed behavior. No screenshot was captured because this is server-side request validation with no changed visual surface.

Evidence: Safari null-Origin login HTTP transcript

CAPTURED SAFARI-SHAPED BRIDGE LOGIN VERIFICATION

Request 1 (correct passcode, value redacted):
POST /login HTTP/1.1
Host: bridge.test.example
Origin: null
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Content-Type: application/x-www-form-urlencoded
Referer: <absent>

Actual response:
HTTP/1.1 303 See Other
Location: /
Set-Cookie: fm_bridge_sid=<redacted>; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=604800

Request 2 (same correct passcode, value redacted):
POST /login HTTP/1.1
Host: bridge.test.example
Origin: NuLl
Sec-Fetch-Site: <absent>
Referer: <absent>
Content-Type: application/x-www-form-urlencoded

Actual response:
HTTP/1.1 403 Forbidden

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

• git diff --unified=80 6c2b65a5e8d72552dae701f03401ce665d159887..7956b3f13f24722d74a55bd0d4f4498577854871 -- bin/fm-bridge-view.py docs/bridge-view.md tests
• tests/fm-bridge-view.test.sh
• Manual live bridge HTTP check: exact Safari request shape (Origin: null, Sec-Fetch-Site: same-origin, Sec-Fetch-Mode: navigate, no Referer, form content type) with correct passcode
• Manual negative live bridge HTTP check: mixed-case Origin: NuLl without Fetch Metadata or Referer proof

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.