[TueJon]

Public PR tests currently run as vd alongside host deployment credentials. Route them to the prepared ci-public account, which has no sudo/Docker access and cannot traverse /home/vd. Keep fork guards and approval requirements, and verify the account boundary in each run.

Validation: this PR runs the existing full CI on the isolated runner. Host rollout is tracked by vdfw-runner-privilege-separation-2026-10-22; existing runner retirement follows green main/deploy evidence and the required host approval.

[TueJon]

Verdict: ship_it — no blocking findings.

First review of this PR (no prior reviews). Scope is .github/workflows/ci.yml only: it pins the job to the ci-public runner label and adds a pre-checkout isolation assertion chain. The fork guard, event triggers and permissions: contents: read are unchanged, and this repository has no deploy workflow, so blast radius is test CI only.

Verified at this head:

• Runner vd-fw-webmcpify-public (id 22) is online with self-hosted,Linux,X64,tuejon-ci,ci-public, so the eager runs-on match is satisfiable; the original vd runner (id 21) does not carry ci-public and can no longer pick up this job.
• Exact-head run 40104657111 / job 120903933011 executed on vd-fw-webmcpify-public, with both Verify runner isolation and npm run check green.
• The asserted account state matches the live host: user ci-public is in group ci-public only (no sudo/docker), /home/vd carries a named deny ACL for that account, and the unit runs under ci-public with NoNewPrivileges, an empty capability set and Docker socket paths inaccessible.
• The assertions run before actions/checkout, so no repository-controlled code executes before the boundary check, and a mislabelled privileged runner would fail the job rather than silently run public code as vd.

Notes (non-blocking, separately owned):

• The ci-public unit is currently active but not enabled at boot. After a host reboot this label disappears and main CI would queue until the rollout starts the unit; that activation belongs to vdfw-runner-privilege-separation-2026-10-22, not to a change in this PR.
• This diff does not claim to contain an approved hostile workflow that rewrites its own runs-on; that remaining limit is documented on the host side and is not introduced here.