docs: name the eSignet provider generation the lab runs

[jeremi]

Why

Two problems with how this repository names the eSignet authenticator it deploys.

1. The exact-URL release pins in versions.env, and the checker that enforces them, still pointed at github.com/jeremi/esignet-relay-authenticator. The repository has moved to github.com/registrystack/esignet-relay-authenticator, so the pins named a location the project no longer owns.
2. docs/esignet.md describes the v0.2.0 profile: a Java plugin JAR built into mosipid/esignet-with-plugins, authenticating against Registry Relay. The upstream authenticator's v0.3.0 release replaced that with a Go provider compiled into eSignet v2.0.0-beta.1 that reads a Base Registry Engine registry through one governed lookup carrying a Registry Mint token, and ships an OCI image tar rather than a JAR. A reader comparing the page against the current release finds a different plugin, a different runtime and a different registry, with nothing saying which generation the lab runs.

This lab deploys no Base Registry Engine, and v0.3.0 defers Relay support, so it cannot move to v0.3.0. The fix is to say so, not to rewrite the flow.

What changed

• versions.env: the three authenticator URLs repointed to the registrystack/ namespace. The tag, asset names and SHA-256 pins are unchanged.
• scripts/check-registry-stack-release-pin.py and scripts/test_registry_stack_release_pin.py: the same repoint, test fixture first.
• docs/esignet.md: a paragraph after the opening naming the v0.3.0 generation, what it changed, and why the lab stays on the v0.2.0 JAR profile the rest of the page describes.

No compose file, image pin, scope, credential or route changed. Nothing here touches auth, authorization, credential issuance, disclosure, redaction, audit, replay, config trust or signing behaviour: the authenticator artifact identity (tag plus digest) is byte for byte what it was, only the host path is corrected. I verified the registrystack/ URLs resolve and that the published .sha256 matches versions.env.

Checks

Run:

• just generate: pass
• just lint: pass (ruff, check-fiction.sh, check-config-secrets.py, check-image-pins.py, hosted-image-manifest.py inventory, check-runtime-topology.py, check-registry-stack-release-pin.py, check-signer-public-keys.py, portal and home svelte-check at 0 errors, 0 warnings)
• just test: 254 Python tests, 1 failure, see below, plus the generator, scenario-runner, portal and home suites

Skipped, no running stack in this environment:

• just smoke and just review

Pre-existing failure, unrelated to this change: scripts/test_smoke_programme_acceptance.py::test_all_programme_and_generic_refusal_checks_pass asserts the captured stderr is empty, and a ResourceWarning: unclosed database surfaces inside its redirect_stderr block. It reproduces on this branch's merge base with these commits reverted, and the test passes when run on its own, so it is an ordering-dependent flake from an unclosed sqlite3 connection in the generator being collected during that capture window. Flagging rather than fixing, since it is outside this change.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-09T16:07:25.075717Z	bfd187a	PR opened

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.