Add GitHub Actions execution for Artificer

[BjRo]

Motivation

Add GitHub Actions as a separately delivered Artificer execution option after the complete local version. The canonical specification and shared delivery rules are in #126.

Authentication investigation may happen before local delivery is complete. Unresolved Actions authentication, cross-job restoration, or execution mechanics must not block acceptance of the local version.

Actions behavior and constraints

• Preserve the parent's eligibility and ownership labels, repository-wide WORK_IN_PROGRESS_LIMIT, independent MAX_STARTS_PER_ACTIVATION, shared admission lock, reservation-before-launch rule, claim lifetime, and recovery policy.
• Each new reservation consumes its activation allowance even when launch fails or is ambiguous. No replacement tickets are admitted during that activation.
• Adapt scheduling, delivery correlation, independent cancellation, and encrypted native-session storage to GitHub Actions. Preserve one independently cancellable delivery workflow run per ticket and shared admission exclusion with cancellation disabled for the admission lock.
• Questions and explicit replies remain GitHub issue comments with the parent's permission, addressing, and duplicate-handling rules. Continue the original native delivery owner rather than replacing it.
• Resolve and validate restoration of the original native parent session and engineering owner across separate Actions jobs. Preserve history, model, and reasoning effort. Local session persistence is not proof of cross-job portability.
• Preserve the configurable five-day default session retention and encrypted archives, with authentication credentials stored separately. Lost or expired state retains the claim for human recovery.
• Resolve coordinated repository-wide exclusion before supporting simultaneous local-and-Actions admission. Separate local and Actions locks alone cannot enforce the shared limit across environments.
• Reuse delivery rules without introducing a general runner framework, Darrow daemon, private queue, workflow database, or execution controller.

Authentication evidence

The maintainer's subscription is ChatGPT Pro 20x. Do not assume it supplies a standalone personal access token: current Codex access-token documentation covers ChatGPT Business and Enterprise workspaces.

• Access-token reference: https://learn.chatgpt.com/docs/enterprise/access-tokens
• Subscription-authentication CI reference: https://learn.chatgpt.com/docs/auth/ci-cd-auth

The documented subscription-authentication workflow for CI excludes public/open-source repositories. Darrow is public, so this authentication route remains unresolved; self-hosting alone does not settle it. No separately billed authentication route has been accepted for this follow-up.

Acceptance criteria

• Establish and document an authentication approach applicable to Darrow's public repository and the chosen account/runner arrangement, including its billing implications. Do not treat a Pro personal access token or self-hosting as an assumed resolution.
• Run the parent's shared admission and claim-lifetime cases through actual Actions scheduling and launch boundaries. Overlapping activations respect their own admission allowances and collectively respect repository-wide WIP and exclusive ownership.
• Reserve under the shared admission lock before launch. Failed or ambiguous launches retain claims, consume the activation allowance, and do not cause replacement admissions during that activation.
• Each ticket delivery is independently identifiable and cancellable. Cancelling one execution leaves other deliveries unaffected, retains the claim for human recovery, and does not undo prior external effects.
• Demonstrate with actual cross-job integration evidence that a later Actions job restores the same native parent and engineering owner, preserving history, model, and reasoning effort. A fresh owner supplied with a summary does not pass.
• Authorized issue replies reach the original owner, including while new admissions are paused. Ordinary, unauthorized, duplicate, or ambiguous comments cause no unintended continuation. Continuation does not consume new-admission allowance.
• Encrypted session archives preserve the agreed retention and credential separation. Missing, corrupt, expired, or unrestorable state causes visible human recovery with no automatic replacement owner or claim reclamation.
• Reconcile ambiguous launch and publication outcomes against authoritative Actions, branch, and PR observations before repeating an external effect.
• If simultaneous local-and-Actions admission is supported, demonstrate repository-wide mutual exclusion and WIP accounting across both environments.
• The completed local version remains independently usable and accepted throughout this follow-up.

Open questions

• Which authentication approach and billing arrangement can support Actions execution for this public repository?
• Which supported Codex version and complete native state permit faithful restoration of the original parent and engineering owner on a later job?
• What Actions-specific scheduling, correlation, cancellation, credential, encryption-key, and storage mechanics satisfy the shared contract?
• What coordinated admission mechanism is required if local and Actions execution are enabled simultaneously?

Repository context: docs/specs/layer-composition.md, docs/specs/ticket-to-pr.md, and docs/specs/adaptive-delivery.md.