Scope vsock exec channel to AI Sandbox + drop App Store doc references

[DaxxSec]

Summary

Two changes on this branch. Happy to split into separate PRs if preferred.

1. Scope vsock exec channel to AI Sandbox VMs only (commit 1ba53fe)

Removes two unconditional attachments from createVirtualMachine() (the generic non-AI-sandbox VM startup path) in AppDelegate.swift:

• VZVirtioSocketDeviceConfiguration attach removed. The if isMacOS { socketDevices = [...] } block predated the AI Sandbox getting its own dedicated config path (AISandboxMacVMConfiguration, which attaches its own vsock device). Without this change, every regular macOS guest carried a vsock device on port 2222 — fine for an AI Sandbox VM, but a latent control-channel surface on any non-AI-sandbox macOS VM, including hypothetical macOS malware-analysis VMs. The port number is documented in open-source code, so the surface is reachable by an adversary inside such a VM cooperating with a host-side process. With no device, there is no port to bind.
• VsockExecBridgeManager.startBridge() call removed. Already inert after the first change because the bridge guards on vm.socketDevices.first is VZVirtioSocketDevice, but the explicit call kept the wiring "one config change away" from re-exposing the channel. AI Sandbox VMs still start their bridge from their own session-boot site (bootAISandboxSession path, ~AppDelegate.swift:2714), so nothing legitimate loses access.

VirtioFS shares were already AI-Sandbox-only (directorySharingDevices is set in exactly one place: AISandboxMacVMConfiguration.swift). With this change, the cross-boundary surfaces that the purple-team proposal targets (VirtioFS workspace + vsock exec bridge) are both structurally confined to the AI Sandbox path.

Context: proposals/purple-team-agent-sandbox.md in anthropic-detections-platform (purple-team writeup; "Adjacent hardening" section flags this fix).

2. Drop $6.99 App Store references from in-repo docs (commit 68b0dc1)

App Store fork was axed (sandbox would strip VirtualNetworkSwitch and PacketCaptureManager). Updating docs that still framed the dual-distribution plan as active:

• docs/LICENSE-REVIEW.md: rewritten for direct-distribution-only. App Store plan named as dropped with a pointer to PRE-LAUNCH-PLAN.md. Copyleft warning kept (still matters for MIT codebase hygiene); App-Store-EULA framing removed.
• siem/yara-scanner/rules/README.md: CC BY-NC 4.0 advisory no longer references an "App Store paid build" — clarifies the official free build is fine with these rules, with the constraint flagged for any future commercial redistributor.
• docs/POST-AUDIT-TODO.md: in-repo sweep checked off. Website/wiki sweep (in the separate daxxsec.tech repo) and memory-note update remain open.
• docs/PRE-LAUNCH-PLAN.md: untouched — its App Store mention explains why the channel wasn't pursued, still useful context.

Out of scope for this PR: the actual website at secvf.daxxsec.tech lives in DaxxSec/daxxsec.tech (private), which is outside my repo allowlist — flagged for separate cleanup.

Test plan

• Build: xcodebuild -scheme SecVF -configuration Debug -destination 'platform=macOS,arch=arm64' build
• AI Sandbox VM: boot via the AISandbox path; confirm /tmp/secvf-exec-<UUID>.sock still appears and secvf-cli vm exec still drives the guest.
• Regular macOS VM (non-AI-sandbox): boot; confirm no /tmp/secvf-exec-*.sock appears for this VM; confirm VM boots and operates normally.
• Linux VM (Kali router): boot; confirm unchanged behavior.
• Stop/restart cycles for each VM type — verify stopBridge calls are still safe no-ops where no bridge exists.
• Docs: confirm no remaining doc framing treats the App Store fork as an active plan.