feat(registry): ensure all elected versions can be parsed

[pierugo-dfinity]

This PR adds a registry invariant that ensures all elected GuestOS and HostOS versions can be parsed by the replicas that will consume them.

Note the

This wouldn't happen in practice (because of validation that happens elsewhere)

here, which referred to validation when updating the StandardEngineReplicaVersion in governance, but the registry itself did not validate them. In particular, versions were not validated neither at election nor at deployment to regular subnets.

[Copilot]

Pull request overview

Adds registry invariants ensuring elected GuestOS and HostOS version IDs are parseable by their consumers.

Changes:

• Validate elected replica and HostOS version IDs.
• Add positive and negative invariant tests.
• Document the new invariant.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
rs/registry/canister/unreleased_changelog.md	Documents version-ID validation.
rs/registry/canister/src/invariants/replica_version.rs	Validates elected replica versions and adds tests.
rs/registry/canister/src/invariants/hostos_version.rs	Validates registered HostOS versions and adds tests.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to bad42fe.

Security Overview

• 🔎 Scanned files: 3 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f975f1a5-0a47-4a3b-b7f0-a55609e90390?scanId=316ced1c-dc20-4019-971d-0f866f1caea9&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► rs/registry/canister/src/invariants/hostos_version.rs     ...; add HostosVersion type import and invariant checks for well-formed version IDs ► rs/registry/canister/src/invariants/replica_version.rs     ...; enforce well-formed ReplicaVersion IDs for elected versions
Other	► rs/registry/canister/unreleased_changelog.md     ...; document invariant about well-formed version IDs for GuestOS/HostOS versions

1. Done.
2. No, not really, all elected replica versions were already satisfying the introduced validation.
3. No data migration needed. I just checked the set of elected replica versions and they all fit the format. Hopefully no bad version gets elected until this gets merged.
4. No security review needed.