Plan-based step naming; retire the diag watcher and actions:read

[matthewdevenny]

Rollout order after #94 (attribution, PR #95): #103 → #106 → #104 → #105. This is next.

Why

Phase 0 resolves step ordinals to GitHub step names by mapping each step_boundary fork timestamp into the step windows from the GitHub API. That works (verified on real runners) but is inference, and it already needed one fix — GitHub reports step timings at second granularity, so back-to-back cheap steps tie and the assignment had to be made monotonic to keep them distinct.

The durable answer is to take step identity from the job plan the action already parses, not from timings. Doing that also removes the last reason the action needs the GitHub API at all.

Scope

cargowall-action

• Pass the parsed job plan (ordered step contextName / id / display names) to the daemon. The action already parses this from the Worker diag log into /tmp/cargowall-step-plan.json.
• Delete the resident _diag/blocks watcher (200ms poll) and /tmp/cargowall-step-timestamps.jsonl — the summary groups causally now, so the timestamp data is redundant.
• Delete the listJobsForWorkflowRun call and drop actions: read from the documented permissions. Replacement sources: step results and the matrix job display name from the Worker-log parse, or authoritative job conclusion via a SaaS-side webhook after the job ends (better than in-job inference, which runs before the job concludes).
• Note: the only change required for Phase 0 itself is the CARGOWALL_VERSION bump; this issue is the cleanup that follows.

cargowall

• Accept the plan (flag or file) and prefer plan-based names in resolveOrdinalSteps; keep the timestamp mapping as the fallback for older action versions.
• Retire correlateEventsToSteps to legacy-only status (already the case in PR #94 causal per-step attribution of network events (phase 0) #95) and consider removing it once no supported action version needs it.

Why it goes first

• The actions: read removal is a user-visible security win (that grant exposes run logs/artifacts repo-wide) and shouldn't wait behind a multi-week kernel project.
• Phase 2 policy selectors key on the stable YAML step id:; plan-based identity is the prerequisite for that.
• Container attribution (Phase 3) wants exact "which step launched this container" identity too.

Done when

• A job with duplicate/unnamed steps resolves every ordinal to the right step without consulting step timings.
• The action's README permission block no longer lists actions: read, and the enforce-mode integration job still asserts boundary events + real ordinals.