sudo always replaces PATH with secure_path, so `sudo -E
$CORONARIUM_BIN run -- pnpm test` failed with `spawning pnpm: No
such file or directory`. Wrap with `env "PATH=$PATH"` so the
runner user's PATH reaches the supervised child.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: bokuweb <[email protected]>

Restructures the matrix job so every `run:` step (corepack enable,
build-ui.sh, cargo test, pnpm install, pnpm build, pnpm test) runs
inside a single coronarium-supervised invocation on Linux + Windows.
macOS keeps the unsupervised path.

The policy is now true default-deny on all three pillars:

- network: explicit allow for 127.0.0.53:53 (systemd-resolved stub),
  github.com / codeload.github.com / objects.githubusercontent.com
  (build-ui.sh git clone), registry.npmjs.org (pnpm install), and
  index.crates.io / static.crates.io / crates.io (cargo deps).
  Anything else fails the connect at the cgroup eBPF layer.

- file: default deny + a broad FHS allow list (/bin /sbin /lib
  /lib64 /usr /etc /proc /sys /dev /tmp /run /var /opt /snap /home
  + C:\ on Windows), with a sensitive-path deny overlay (shadow /
  sudoers / ssh host keys / .ssh / .aws / .gnupg / .netrc /
  .docker / docker.sock / /var/run/secrets, plus Windows
  equivalents). Deny wins over allow, so the credential paths stay
  locked even though /etc and /home are on the allow list.

- process.deny_exec: basename-match block on curl / wget / nc /
  ncat / socat / ssh / scp / sftp / rsync / telnet / ftp. Tests
  legitimately need node, pnpm, sh, bash, git, cargo, vite — none
  of these tools.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: bokuweb <[email protected]>

The first block-mode run failed because cargo's git fetch of
`image-diff-rs` from github.com hit a different IP than the one
captured at coronarium startup — github.com's GeoDNS rotates.
coronarium does support hostname re-resolution via
`--dns-refresh-interval <secs>`, which additively populates the
BPF map; enable it with a 30s interval on Linux + Windows.

Also reorder `file.deny`: coronarium kernel-blocks only the first
eight prefixes (`file.deny has more than 8 entries — remaining
are audit-tagged only`). Promote the most catastrophic-on-leak
paths (shadow / sudoers / .ssh / .aws / .gnupg / .netrc /
.docker / docker.sock) into the kernel-enforced slots; the rest
stay in the policy as audit-only tags.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: bokuweb <[email protected]>

Two failure modes from the first block-mode run with the new
default-deny policy:

1. Linux: `git clone` died with `git-remote-https died of signal 9`
   on its first connect. libcurl (git's HTTPS backend) probes
   `$HOME/.netrc` on every HTTPS request for credential lookup,
   and coronarium's kernel-side LSM hook matches on the path
   string before filesystem resolution — so the deny fires (and
   sends SIGKILL) even though `.netrc` doesn't exist on a fresh
   runner. Same probe happens from pnpm and cargo's HTTPS code
   paths. Drop `.netrc` from `file.deny`; the deny had near-zero
   value (file is empty/absent) but breaks every HTTPS call.

2. Windows: 51 tests passed but coronarium-win exited non-zero
   with `policy violation: 417360 events denied`. coronarium-win
   itself warns `network.default=deny on Windows is audit-only`
   — Windows Defender Firewall has no clean default-outbound-deny
   primitive, so coronarium-win tags every TLS connect as denied
   in the log without actually blocking it, and `--mode block`'s
   `denied > 0 → exit 1` rule then fails tests that were never
   blocked. Force `--mode audit` on the Windows run and rely on
   Linux for real enforcement.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: bokuweb <[email protected]>

The first green-tests Linux block-mode run still failed with
`policy violation: 7925 events denied`. Audit log shows 57 of
those are TCP connects from `node` to `104.16.x.34` and
`2606:4700::*` — i.e. Cloudflare anycast IPs. registry.npmjs.org
is fronted by Cloudflare and pnpm picks IPs across the /12 that
coronarium's 15s DNS refresh can't enumerate (anycast advertises
the same prefix from many POPs; each DNS query returns a fresh
small subset).

Whitelist Cloudflare's published v4/v6 ranges
(https://www.cloudflare.com/ips/) so the CDN-fronted downloads
work. This widens the egress allowance to "any service on the
same Cloudflare POP", but that is the same effective blast
radius we already accepted by allowing the hostname.

(The remaining 3 denied opens with `filename=""` look like a
coronarium-side bug — empty path strings fall through allow checks
and hit `default: deny`. Will follow up upstream; not a blocker
here.)

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: bokuweb <[email protected]>

Previous run still hit `policy violation: 7011 events denied` even
with the deny list trimmed to exactly 8 kernel-blocked entries.
coronarium's sample buffer is biased toward startup events (192
samples of 92152 observed, none with denied=true), so the JSON
log doesn't tell us *which* paths were denied — but the count and
the fact tests still pass (no SIGKILL) point at one cause:

The supervised process opens many anonymous file descriptors —
`pipe:[123]`, `anon_inode:[eventfd]`, `socket:[N]`, `memfd:…` —
whose "paths" aren't real filesystem paths. None match `/lib/`,
`/etc/`, etc. prefixes, so under `default: deny` they fall
through and increment `stats.denied`. pnpm install of ~800
packages spawns thousands of such fds and the run fails block
mode every time. The matcher already has a sibling guard for
empty paths (#42 in v0.31.0); a follow-up to also skip non-
absolute paths would let `default: deny` work, but that's
upstream work.

For now, switch the file pillar back to `default: allow`. The 8
kernel-blocked deny prefixes still fire SIGKILL on attempted
credential reads regardless of the default verdict — that's the
actual defence-in-depth here, and it's intact.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: bokuweb <[email protected]>