feat(atlas-action): add Atlas Action Service (FastAPI control plane, runner, policy gate, docs)

[ryanx0621]

Motivation

• Provide a civilization-grade internal CI/Runner that prioritizes auditability, rollback safety, isolation, and reproducibility.
• Centralize job ingestion (e.g. GitHub webhooks) and enforce policy gates (egress, write-contract, scope) before execution.
• Define a canonical AtlasJobSpec to standardize job definitions and enable adapters from existing workflow formats.
• Offer a Docker-based developer/CI experience and sample configs for reproducible local deployment.

Description

• Add a FastAPI control plane with POST /webhooks/github, GET /jobs/{job_id}, and GET /healthz endpoints under atlas_action_service/atlas_actiond and a top-level Dockerfile and docker-compose.yml for local runs.
• Introduce AtlasJobSpec Pydantic models and a JSON Schema at atlas_action_service/docs/atlas_job_spec.schema.json to canonicalize job payloads.
• Implement a PolicyGate and guard implementations (egress_allowlist, write_contract, etc.) in atlas_action_service/atlas_actiond/policy to evaluate job capabilities before enqueueing.
• Add a Redis-backed JobQueue, an audit logger that records hash-chained entries, artifact helpers, a runner that consumes Redis Streams and executes steps in isolated Docker containers, and convenience scripts and sample config under atlas_action_service/.

Testing

• No automated tests were run on these changes.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 31c73efb06

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Enforce egress based on capabilities, not execution_domain

The runner decides network access solely from execution_domain (read/code => --network none, else bridge), but the policy gate only checks job.capabilities.network_egress for allowlisting (see atlas_action_service/atlas_actiond/policy/guards.py lines 35–37). This mismatch lets a job request execution_domain="network" while keeping capabilities.network_egress=false, which bypasses the allowlist guard and still runs with network access. In any environment where job specs can be supplied by external adapters or users, this is an easy privilege escalation path for egress.

Useful? React with 👍 / 👎.