feat(platform): PortAccess — 80 and 443 without root (T42)

[haiquang9994]

Makes ports 80 and 443 reachable by a front end this daemon runs as an ordinary user: a no-op on
Windows, cap_net_bind_service on Linux, a pf redirect plus a boot-time job on macOS — and re-checks
it on every daemon start.

Design: docs/superpowers/specs/2026-08-23-t42-port-access-design.md.

What lands

A read-only PortAccess capability on Host answers three questions — which mechanism does this
machine use, which port must a program bind to answer 80, is the grant already there — and the
write is two new PrivilegedOp variants that mixengine-elevate validates itself. The daemon probes
at start-up and enqueues a grant only when the probe says one is missing, which makes the producer
and the after-update re-probe the same code.

Nothing above mixengine-platform gains a #[cfg]: PortAccessMethod is the data that exists so
core, daemon and CLI can stay free of one.

Decisions worth reading

ADR 0012 — a LaunchDaemon runs /sbin/pfctl -e -f /etc/pf.conf at boot on macOS. pf is disabled
on every boot and pfctl -e needs root, so a redirect that is only installed works until the first
reboot and then silently stops. This is the first thing MixEngine installs that acts without anybody
asking, so CLAUDE.md's "no persistent root process, ever" is qualified rather than quietly bent:
one fixed command, root-owned, no argument from anywhere, KeepAlive false.

Revoke names its target. A Linux capability lives on a file, so taking it back means naming that
file; reusing PortAccessPlan would have carried ports into an operation that does not read them,
which is the field the split exists to forbid.

nftables is not here. The roadmap allowed for it; setcap was measured to work and to be
readable back without privilege, so a second Linux mechanism would have been a branch nothing
exercises.

T88b is closed by this task. Probing at every start catches a capability lost to something that
was not an update and needs no hook in the updater. Two tasks describing one behaviour is what was
avoided.

What was proven on a real machine

CI's system job, all three runners green:

• Linux — the attribute is written, read back through the ordinary unprivileged probe, cleared by
  the kernel when the file is overwritten, and taken away again. The loss is the half that matters:
  it is what the argument for granting a capability on a user-writable file rests on.
• macOS — the redirect is installed, pfctl -e loads it, a server on 8080 is reached through
  127.0.0.1:80, and after revoke /etc/pf.conf is byte-identical to the one Apple ships with
  nothing of ours left in /etc/pf.anchors or /Library/LaunchDaemons.
• Windows — no leg, because that system's whole answer is a refusal and a refusal needs no token.
  It is asserted in the test job with everything else.

Not here, on purpose

A front end that actually listens on the granted port, and a site reachable end to end, are T43.
Reporting and repairing port access is T47. A producer for PortAccessRevoke is T87's, and the
operation ships built, validated and tested with none.

Recorded debt: two accounts on one machine share one grant, and on macOS one anchor with one pair
of redirect targets — the second home's front end will want 8080 too and will fail to bind it. The
same debt T41 recorded for the hosts file, for the same reason.