Reintroduce n2c legs in the GitHub-runner e2e suite

[scarmuega]

Background

The e2e suite was migrated from EKS/Kubernetes to GitHub-hosted runners (#927). Each leg now runs the release image via docker run + timeout and gates on the process exit code (a WorkStats finalization policy makes oura self-terminate with exit 0; an Assert panic exits non-zero; a hang is caught by timeout).

Two n2c legs — assert-n2c-preview-origin-blocks and assert-n2c-preview-tip-blocks — were removed in that migration (commit 3b53307) because, unlike the other sources, n2c needs a local node-to-client Unix socket that the runner has no way to provide out of the box. This issue tracks bringing them back once the supporting infra exists.

Why n2c is the hard case

The other legs are self-contained on a hosted runner:

• n2n connects over TCP to public relays (the Demeter relay.cnode-m1.demeter.run endpoints).
• u5c connects over TLS/gRPC to the Demeter UTxORPC endpoints.
• aws sinks talk to AWS over the network.

n2c speaks the node-to-client mini-protocol over a local Unix socket — there is no public n2c endpoint to dial. In the old k8s suite this was solved with a socat sidecar bridging the Unix socket to an in-cluster Cardano node's TCP port (*.svc.cluster.local). That in-cluster node is exactly the dependency the runner migration set out to remove, so it can't be carried over as-is.

Proposed approach: Demeter dmtrcli port-forward

Expose a Demeter-managed Cardano node's n2c socket onto the runner host via the Demeter CLI, then mount it into the oura container at the socket path the config expects (/opt/cardano/cnode/sockets/node0.socket), so the existing N2C config is reused unchanged.

Sketch (the migration left placeholder scripts; the exact CLI invocation must be confirmed):

- name: Set up dmtrcli node socket (n2c)
  if: matrix.kind == 'n2c'
  env:
    DMTR_API_KEY: ${{ secrets.DMTR_API_KEY }}
  run: |
    dmtrcli auth login --api-key "$DMTR_API_KEY"
    dmtrcli ports tunnel --unix-socket "$RUNNER_TEMP/sockets/node0.socket" &   # exact flags TBD
    # wait for the socket to appear, then docker run with
    #   -v "$RUNNER_TEMP/sockets:/opt/cardano/cnode/sockets"

Open questions / limitations

• Exact dmtrcli surface. The auth + port-forward subcommands/flags above are placeholders and need to be confirmed against the real CLI (does it expose a managed node's n2c socket, on which network/tier, and how is it authenticated?).
• Secret + access. Requires a DMTR_API_KEY secret and a Demeter account/plan that grants n2c socket access on the target network (the legs target preview).
• Lifecycle/flakiness. The tunnel is a background process; the socket must exist before docker run and be torn down after. This is more moving parts than the other legs and a likely flakiness source — worth marking the legs continue-on-error initially, or adding a readiness check + retry.
• Alternative. If a hosted n2c socket via dmtrcli proves impractical, fall back to running a cardano-node sidecar on the runner seeded from a Mithril snapshot (heavier: snapshot restore + node warmup, a few GB of disk), or reconsider whether n2c protocol coverage is needed beyond what n2n already exercises.

Scope when reintroducing

• Re-add assert-n2c-preview-{origin,tip}-blocks.toml configs (N2C source → WorkStats → LegacyV1 → Assert; RollbackBuffer on the tip leg).
• Re-add the matrix entries (kind: n2c) and the dmtrcli setup/teardown steps + the socket mount in run-test.sh.
• Wire the DMTR_API_KEY secret.

These were all present before 3b53307 and can be recovered from that commit's parent as a starting point.