security: the three red-steel fixes that apply cleanly to current main

[CueCrux-Myles]

First slice of the red-steel remediation stranded in #630. These three commits are taken unmodified from codex/crux-red-steel-remediation-2026-07-30 and cherry-pick cleanly onto current main:

commit	fix
a3e2eabf	fix(mcp): fail closed for OAuth-only auth
2d5c085d	fix(security): harden daemon browser responses
014cd05a	fix(security): remove the yanked ZIP crypto path

Verification

• cargo check --workspace --all-targets — clean
• cargo test -p crux-mcp -p corecruxd -p corecrux-receipts -p corecruxctl --lib — 282 / 1229 / 801 passed, 0 failed
• cargo clippy --workspace --all-targets — 17 errors, identical to the main baseline (all pre-existing in rcx-revocation); no new lint debt

Why only three, when five applied cleanly

41ee2515 (test(mcp): assert tenant-isolated actor reads) and 33ec4ed1 (test(observe): scope eviction deletes by tenant) apply textually but are tests for production changes still in the un-rebased set:

• 33ec4ed1 does not compile — it calls store.delete("default", &id), the tenant-scoped signature introduced by ba642868.
• 41ee2515 compiles and fails, which is the interesting one. It asserts a work-tenant query_facts sees 2 rows; on current main it sees 3, the extra being a fact written under the default tenant. main and red-steel disagree about whether default-tenant facts are visible cross-tenant, and red-steel's ba642868 / 426ea8a0 treat that as a leak to close.

Both belong with their production commits, not here.

See #630 for the full picture and the remaining slices.

🤖 Generated with Claude Code

[CueCrux-Myles]

Correction to the PR description, on the 41ee2515 note.

I wrote that main and red-steel "disagree about whether default-tenant facts are visible cross-tenant", which implies a filter is being bypassed. That is not the shape of it.

On main the MCP surface has no tenant dimension at all, by acknowledged design:

• Writes — tenant_hash_for_write_context(_ctx) ignores its context argument and returns default_tenant_hash() unconditionally. Its own doc comment says so: "Authenticated MCP context has no tenant claim yet, so current deployments resolve to default. When one is added, only this helper needs to change."
• Reads — handle_query_facts and memory_view pass tenant_hash: None, and the filter at facts.rs:733 treats None as no filtering.

So the test sees 3 rows because all three facts land in default and the read is unfiltered — not because isolation is being defeated. ba642868 / 426ea8a0 are completing the documented gap, not fixing a regression.

The residual exposure worth tracking: MCP reads are unfiltered, so facts written under a non-default tenant via other ingest paths (HTTP with a JWT tenant claim) would be returned to an MCP caller.

Nothing in this PR's three commits changes; only my characterisation of why 41ee2515 was excluded.