[WIP] Acknowledg Forge

[wchilders-nvidia]

Adds acknowledg-forge, a service that keeps an AcknowlEDG review alive for
each open GitHub or GitLab pull request:

• Test - Changes: rematerialized expectation diffs;
• Test - Failures: from the PR's latest CI run;
• Bench - C / Bench - C++: compared with the checked-in baselines.

It can also comment on the PR when results change. The PR ships the service
as a public container image and deploys it from CI.

Initial drafts for GitHub and GitLab support are both included, primarily to ensure that the core logic is sufficiently abstract that this can conceptually be used with different software forges to allow downstream repositories (of various former EDG customers -- that may be in a variety of different software forges) to also leverage the software for their internal processing.

The code primarily authored by Claude and is at this point very lightly reviewed (mostly at the system configuration level). I'll be making my way through it myself, but wanted to get this up so others can start getting eyes on it.

This will be an important service for us as we start to try and process some of the larger PRs that have broader testing impact (e.g., #201).

As of the initial PR opening there are ~9,750 added lines:

Area	Lines	Weight
Existing libraries modified (edgtest, edgacknowledg.client)	~130	Highest
Workflows	~300	High
Image, packaging, root deploy helper	~500	High (deploy-remote.sh)
Core: dev_tools/pylibs/edgacknowledg/forge/	~3,400	High
Forge adapters (GitHub, GitLab)	~700	Medium
Tests	~1,950	Medium
Docs	~480	Medium
uv.lock files	~1,900	Generated; run uv lock --check

Read in this order:

1. Changes to existing code (below).
2. dev_tools/services/acknowledg-forge/README.md, the design overview.
3. forge/__init__.py, the protocols.
4. The processing path: ingest → db/store → processor → publisher →
   announcer.
5. The security boundaries and the deploy helper

Changes to existing code

• edgtest: .run_test_env is no longer sourced. Sourcing it was
  arbitrary code execution for untrusted PRs. No such files are tracked here.
  Does any out-of-tree test home use one?
• edgacknowledg.client (all CLIs are affected):
  • a handler exception replies invalid and the section keeps serving;
  • subscribe and unsubscribe time out;
  • section changes and reconnect restores are serialized by one lock.
    The library still supports Python 3.6.
• client.test / client.bench: an optional command_prefix
  (sandboxing for ifc-dump and cg_annotate).
• AcknowlEDG server wheel excludes edgacknowledg.forge.
  edgdocker registers the image.
• acknowledg-deploy.yml: the API URL comes from a repository
  variable; forge-only changes don't trigger it.

Security boundaries

• sandbox.py: everything that touches PR content runs in bwrap:

  • no network, a cleared environment, read-only inputs, one writable output
    directory;
  • the EDG tooling is a frozen copy from the image, never the PR's;
  • the service refuses to start without a working sandbox.

• workspace.py:

  • artifact extraction rejects escaping paths and links, and caps the
    decompressed size (including inner .rt.tar.gz files);
  • no writes through symlinks;
  • git runs with no hooks, and credentials never go in argv.

• Webhooks:

  • signatures checked in constant time;
  • payloads only identify what changed, and state is always re-fetched;
  • unconfigured repositories are ignored, and the queue is deduplicated.

• http.py: artifact downloads that redirect to storage don't send
  credentials. They're size-capped.

• Comments contain no PR-supplied text.

• deploy-remote.sh runs as root, through sudo, and is installed
  by an admin:

  • it accepts only ghcr.io/edgcpp/acknowledg-forge@sha256:…, path-free
    ws(s)/http(s) URLs, and acknowledg-forge-* service names;
  • it writes only a root-owned drop-in.

  What can someone holding the deploy key do? Intended answer: deploy
  another image published from this repository.

• The publish job has no access to environment secrets, and the image
  contains no credentials or configuration.

Core logic

• Store:
  • a generation counter marks PRs dirty;
  • a base-branch push alone isn't material, so PRs aren't all reprocessed on
    every push to main;
  • work completed for an older generation doesn't clear a newer change;
  • retries back off, and the service gives up after 8 attempts until the PR
    changes.
• Processor:
  • Changes: keyed by (merge-base, head).
  • Failures: from the latest completed CI attempt, kept while a new run
    is in progress, dropped when CI passes.
  • Run directories are swapped in by rename.
  • Closing a PR removes its workspace; the clone is deleted only when no
    open PR needs it.
• Publisher: one batch connection, read-only sections, and dropped
  sections are re-added.
• Announcer:
  • comments only when a PR is settled and its content fingerprint changed;
  • nothing on restart, close, or reopen;
  • a fresh database adopts existing PRs silently;
  • posting is idempotent, using a marker in each comment.
• Database: portable types and an Alembic migration that matches the
  models. The test suite passes on PostgreSQL 17 as well as SQLite.
• Adapters: GitHub maps pull request state, run_attempt, and
  artifacts. GitLab maps per-job artifacts and URL-encoded project paths, and
  is tested only against mocked APIs.

Verification

Verified:

• Tests:
  • the PR lifecycle against a fake forge;
  • the publisher against a real AcknowlEDG server;
  • sandbox, archive, and symlink attacks;
  • webhook signatures and idempotent comments;
  • SQLite and PostgreSQL.
• Inside the image, under rootless Podman: nested bwrap, the frozen
  tools, SIGTERM shutdown, credentials, and volume ownership.
• Tooling:
  • strict mypy, plus the existing typecheck (Python 3.14 and 3.6);
  • actionlint;
  • a Quadlet dry run;
  • the deploy helper with stubbed systemctl/podman.

Not verified:

• real GitHub or GitLab APIs, and the new workflows running on GitHub;
• the host procedure on a real server: root-created user-scoped credentials,
  users/<UID> Quadlet units, PostgreSQL peer authentication, and Ubuntu's
  AppArmor user-namespace restriction.

Known limitations

• Test - Changes is not served until edg-rematerialize-test-run writes
  changes.elist.
• Tooling changes need a new image, because the tooling is frozen into
  it. The deploy workflow rebuilds it on any dev_tools/bin or
  dev_tools/pylibs change.